Hash: SHA1


Recently there was a brouhaha over Coinbase censoring the ability of
firearms businesses to accept bitcoins via Coinbase

The question and relevance here to this is that for people who are
going for the alternate route (e.g., bailing on Coinbase / Bitpay /
similar web wallets, in favor of setting up with something like
Electrum and using Gear https://gear.mycelium.com/ as payment
processor or Straight
what would be the answer to "What does this mean for me?" for this topic

On 06/19/2015 03:39 AM, Peter Todd wrote:
> Yesterday F2Pool, currently the largest pool with 21% of the
> hashing power, enabled full replace-by-fee (RBF) support after
> discussions with me. This means that transactions that F2Pool has
> will be replaced if a conflicting transaction pays a higher fee.
> There are no requirements for the replacement transaction to pay
> addresses that were paid by the previous transaction.
> I'm a user. What does this mean for me? 
> ---------------------------------------
> In the short term, very little. Wallet software aimed at average
> users has no ability to reliably detect conditions where an
> unconfirmed transaction may be double-spent by the sender. For
> example, Schildbach's Bitcoin Wallet for Android doesn't even
> detect double-spends of unconfirmed transactions when connected to
> a RBF or Bitcoin XT nodes that propagate them. The least
> sophisticated double-spend attack possibly - simply broadcasting
> two conflicting transactions at the same time - has about 50%
> probability of success against these wallets.
> Additionally, SPV wallets based on bitcoinj can't even detect
> invalid transactions reliably, instead trusting the full node(s) it
> is connected too over the unauthenticated, unencrypted, P2P
> protocol to do validation for them. For instance due to a unfixed
> bug¹ Bitcoin XT nodes will relay double-spends that spend the
> output of the conflicting transaction. I've personally tested this
> with Schildbach's Bitcoin Wallet for Android, which shows such
> invalid transactions as standard, unconfirmed, transactions.
> Users should continue to assume that unconfirmed transactions could
> be trivially reversed by the sender until the first confirmation.
> In general, only the sender can reverse a transaction, so if you do
> trust the sender feel free to assume an unconfirmed transaction
> will eventually confirm. However, if you do not trust the sender
> and/or have no other recourse if they double-spend you, wait until
> at least the first confirmation before assuming the transaction
> will go through.
> In the long term, miner support of full RBF has a number of
> advantages to users, allowing you to more efficiently make
> transactions, paying lower fees. However you'll need a wallet
> supporting these features; none exist yet.
> I'm a business. What does this mean for me? 
> -------------------------------------------
> If you use your own node to verify transactions, you probably are
> in a similar situation as average users, so again, this means very
> little to you.
> If you use a payment processor/transaction API such as BitPay,
> Coinbase, BlockCypher, etc. you may or may not be accepting
> unconfirmed transactions, and they may or may not be "guaranteed"
> by your payment processor even if double-spent. If like most
> merchants you're using the API such that confirmations are required
> prior to accepting orders (e.g. taking a meaningful loss such as
> shipping a product if the tx is reversed) nothing changes for you.
> If not I recommend you contact your payment processor.
> I'm a miner. Why should I support replace-by-fee? 
> -------------------------------------------------
> Whether full or first-seen-safe⁵ RBF support (along with 
> child-pays-for-parent) is an important step towards a fully
> functioning transaction fee market that doesn't lead to users'
> transactions getting mysteriously "stuck", particularly during
> network flooding events/attacks. A better functioning fee market
> will help reduce pressure to increase the blocksize, particularly
> from the users creating the most valuable transactions.
> Full RBF also helps make use of the limited blockchain space more 
> efficiently, with up to 90%+ transaction size savings possible in
> some transaction patterns. (e.g. long payment chains⁶) More users
> in less blockchain space will lead to higher overall fees per
> block.
> Finally as we'll discuss below full RBF prevents a number of
> serious threats to the existing level playing field that miners
> operate in.
> Why can't we make accepting unconfirmed txs from untrusted people
> safe? 
> ----------------------------------------------------------------------
- -
>  For a decentralized wallet, the situation is pretty bleak. These
> wallets only have a handful of connections to the network, with no
> way of knowing if those connections give an accurate view of what
> transactions miners actually know about.
> The only serious attempt to fix this problem for decentralized
> wallets that has been actually deployed is Andresen/Harding's
> double-spend relaying, implemented in Bitcoin XT. It relays up to
> one double-spend transaction per double-spent txout, with the
> intended effect to warn recipients. In practice however this
> functionality makes it easier to double-spend rather than harder,
> by giving an efficient and easy way to get double-spends to miners
> after the fact. Notably my RBF implementation even connects to
> Bitcoin XT nodes, reserving a % of all incoming and outgoing
> connection slots for them.
> Additionally Bitcoin XT's double-spend relaying is subject to
> attacks include bandwidth exhaustion, sybil attacks, and Gervais's
> non-sybil interactive attacks⁷ among many others.
> What about centralised wallets? -------------------------------
> Here the solutions being deployed, planned, and proposed are
> harmful, and even represent serious threats to Bitcoin's
> decentralization.
> Confidence factors ------------------
> Many services such as BlockCypher² have attempted to predict the 
> probability that unconfirmed transactions will be mined, often 
> guaranteeing merchants payment³ even in the event of a
> double-spend. The key component of these predictions is to sybil
> attack the P2P network as a whole, connecting to as many nodes as
> possible to measure transaction propagation. Additionally these
> services connect to pools directly via the getblocktemplate
> protocol, repeatedly downloading via GBT the lists of transactions
> in the to-be-mined blocks to determine what transactions miners are
> attempting to mine.
> None of these measures scale, wasting significant network and
> miner resources; in one instance a sybil attack by Chainalysis even
> completely blocked the users of the SPV wallet Breadwallet⁴ from
> accessing the network. These measures also don't work very well,
> giving double-spend attackers incentives to sybil attack miners
> themselves.
> Transaction processing contracts with miners 
> --------------------------------------------
> The next step after measuring propagation fails is to contract
> with miners directly, signing contracts with as much of the hashing
> power as possible to get the transactions they want mined and
> double-spends rejected. The miners/pools would then provide an
> authenticated API endpoint for exclusive use of this service that
> would allow the service to add and remove specific transactions to
> the mempool on demand.
> There's a number of serious problems with this:
> 1) Mining contracts can be used to double-spend
> ...even when they're being used "honestly".
> Suppose Alice is a merchant using CoinPayCypher, who has contracts
> with 75% of the hashing power. Bob, another merchant, meanwhile
> uses a decentralized Bitcoin Core backend for payments to his
> website.
> Mallory wants to double-spend Bob's to buy his expensive products.
> He can do this by creating a transaction, tx1, that pays Alice,
> followed by a second transaction, tx2, that pays Bob. In any
> circumstance when Mallory can convince Bob to accept tx2, but
> prevent Bob from seeing tx1, the chance of Malory's double-spend
> succeeding becomes ~75% because CoinPayCypher's contracts with
> mining ensure the transaction paying Alice will get mined.
> Of course, dishonest use and/or compromise makes double-spending 
> trivial: Malory can use the API credentials to ask miners to
> reject Bob's payment at any time.
> 2) They still don't work, without 51% attacking other miners
> Even if CoinPayCypher has 75% of the hashing power on contract,
> that's still a potentially 75% chance of being double-spent. The
> 25% of miners who haven't signed contracts have no _decentralized_
> way of ensuring they don't create blocks with double-spends, let
> alone at low cost. If those miners won't or can't sign contracts
> with CoinPayCypher the only next step available is to reject their
> blocks entirely.
> 3) Legal contracts give the advantage to non-anonymous miners in 
> Western jurisdictions
> Suppose CoinPayCypher is a US company, and you're a miner with 1% 
> hashing power located in northern China. The barriers to you
> succesfully negotiating a contract with CoinPayCypher are
> significant. You don't speak the same langauge, you're in a
> completely different jurisdiction so enforcing the legal contract
> is difficult, and being just 1%, CoinPayCypher sees you as
> insignificant.
> Who's going to get the profitable hashing power contracts first, if
> at all? Your English speaking competitors in the west. This is
> inherently a pressure towards centralization of mining.
> Why isn't this being announced on the bitcoin-security list first? 
> ------------------------------------------------------------------
> I've had repeated discussions with services vulnerable to
> double-spends; they have been made well aware of the risk they're
> taking. If they've followed my own and others' advice they'll at
> minimum have constant monitoring of the rate of double-spends both
> on their own services and on the P2P network in general.
> If you choose to take a risk you should accept the consequences.
> How do I actually use full RBF? -------------------------------
> First get the full-RBF patch to v0.10.2:
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
> The above implementation of RBF includes additional code to find
> and preferentially connect to other RBF nodes, as well as Bitcoin
> XT nodes. Secondly, try out my replace-by-fee-tools at:
> https://github.com/petertodd/replace-by-fee-tools
> You can watch double-spends on the network here:
> http://respends.thinlink.com/
> References ----------
> 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also
> novel variants of existing attacks w/ Bitcoin XT and Android
> Bitcoin Wallet", Peter Todd, May 23rd 2015, Bitcoin-development
> mailing list, 
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/
>  2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds", June
> 2nd, 2014, Erik Voorhees, 
> https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transact
>  3) Coinbase Merchant API, Accessed Jun 19th 2015, 
> https://developers.coinbase.com/docs/merchants/callbacks#confirmations
>  4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network", 
> March 14th 2015, Grace Caffyn, Coindesk, 
> http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-
>  5) "First-Seen-Safe Replace-by-Fee", May 25th 2015, Peter Todd,
> Bitcoin-development mailing list, 
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.ne
>  6) "Cost savings by using replace-by-fee, 30-90%", May 25th 2015,
> Peter Todd, Bitcoin-development mailing list, 
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/
>  7) "Tampering with the Delivery of Blocks and Transactions in
> Bitcoin", Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame
> and Srdjan Capkun, Cryptology ePrint Archive: Report 2015/578, Jun
> 10th 2015, http://eprint.iacr.org/2015/578
> ----------------------------------------------------------------------
- --------
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
Version: GnuPG v1


Bitcoin-development mailing list

Reply via email to