Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Jeff Garzik <jgarzik@bitpay.com>]

[-- Attachment #1: Type: text/plain, Size: 13032 bytes --]

This is very disappointing.  "scorched earth" replace-by-fee implemented
first at a pool, without updating wallets and merchants, is very
anti-social and increases the ability to perform Finney attacks and
double-spends.

The community is progressing more towards a safer replace-by-fee model, as
indicated by the following code change:
https://github.com/bitcoin/bitcoin/pull/6176


On Fri, Jun 19, 2015 at 3:39 AM, Peter Todd <pete@petertodd.org> 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/msg07795.html
>
> 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-transactions-in-8-seconds-7c9edcb3b734
>
> 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-on-bitcoin-network/
>
> 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.net/msg07829.html
>
> 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/msg07813.html
>
> 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
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 15893 bytes --]