{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-19\n📝 Original message:Yesterday F2Pool, currently the largest pool with 21% of the hashing\npower, enabled full replace-by-fee (RBF) support after discussions with\nme. This means that transactions that F2Pool has will be replaced if a\nconflicting transaction pays a higher fee. There are no requirements for\nthe replacement transaction to pay addresses that were paid by the\nprevious transaction.\n\n\nI'm a user. What does this mean for me?\n---------------------------------------\n\nIn the short term, very little. Wallet software aimed at average users\nhas no ability to reliably detect conditions where an unconfirmed\ntransaction may be double-spent by the sender. For example, Schildbach's\nBitcoin Wallet for Android doesn't even detect double-spends of\nunconfirmed transactions when connected to a RBF or Bitcoin XT nodes\nthat propagate them. The least sophisticated double-spend attack\npossibly - simply broadcasting two conflicting transactions at the same\ntime - has about 50% probability of success against these wallets.\n\nAdditionally, SPV wallets based on bitcoinj can't even detect invalid\ntransactions reliably, instead trusting the full node(s) it is connected\ntoo over the unauthenticated, unencrypted, P2P protocol to do validation\nfor them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay\ndouble-spends that spend the output of the conflicting transaction. I've\npersonally tested this with Schildbach's Bitcoin Wallet for Android,\nwhich shows such invalid transactions as standard, unconfirmed,\ntransactions.\n\nUsers should continue to assume that unconfirmed transactions could be\ntrivially reversed by the sender until the first confirmation. In\ngeneral, only the sender can reverse a transaction, so if you do trust\nthe sender feel free to assume an unconfirmed transaction will\neventually confirm. However, if you do not trust the sender and/or have\nno other recourse if they double-spend you, wait until at least the\nfirst confirmation before assuming the transaction will go through.\n\nIn the long term, miner support of full RBF has a number of advantages\nto users, allowing you to more efficiently make transactions, paying\nlower fees. However you'll need a wallet supporting these features; none\nexist yet.\n\n\nI'm a business. What does this mean for me?\n-------------------------------------------\n\nIf you use your own node to verify transactions, you probably are in a\nsimilar situation as average users, so again, this means very little to\nyou.\n\nIf you use a payment processor/transaction API such as BitPay, Coinbase,\nBlockCypher, etc. you may or may not be accepting unconfirmed\ntransactions, and they may or may not be \"guaranteed\" by your payment\nprocessor even if double-spent. If like most merchants you're using the\nAPI such that confirmations are required prior to accepting orders (e.g.\ntaking a meaningful loss such as shipping a product if the tx is\nreversed) nothing changes for you. If not I recommend you contact your\npayment processor.\n\n\nI'm a miner. Why should I support replace-by-fee?\n-------------------------------------------------\n\nWhether full or first-seen-safe⁵ RBF support (along with\nchild-pays-for-parent) is an important step towards a fully functioning\ntransaction fee market that doesn't lead to users' transactions getting\nmysteriously \"stuck\", particularly during network flooding\nevents/attacks. A better functioning fee market will help reduce\npressure to increase the blocksize, particularly from the users creating\nthe most valuable transactions.\n\nFull RBF also helps make use of the limited blockchain space more\nefficiently, with up to 90%+ transaction size savings possible in some\ntransaction patterns. (e.g. long payment chains⁶) More users in less\nblockchain space will lead to higher overall fees per block.\n\nFinally as we'll discuss below full RBF prevents a number of serious\nthreats to the existing level playing field that miners operate in.\n\n\nWhy can't we make accepting unconfirmed txs from untrusted people safe?\n-----------------------------------------------------------------------\n\nFor a decentralized wallet, the situation is pretty bleak. These wallets\nonly have a handful of connections to the network, with no way of\nknowing if those connections give an accurate view of what transactions\nminers actually know about.\n\nThe only serious attempt to fix this problem for decentralized wallets\nthat has been actually deployed is Andresen/Harding's double-spend\nrelaying, implemented in Bitcoin XT. It relays up to one double-spend\ntransaction per double-spent txout, with the intended effect to warn\nrecipients. In practice however this functionality makes it easier to\ndouble-spend rather than harder, by giving an efficient and easy way to\nget double-spends to miners after the fact. Notably my RBF\nimplementation even connects to Bitcoin XT nodes, reserving a % of all\nincoming and outgoing connection slots for them.\n\nAdditionally Bitcoin XT's double-spend relaying is subject to attacks\ninclude bandwidth exhaustion, sybil attacks, and Gervais's non-sybil\ninteractive attacks⁷ among many others.\n\n\nWhat about centralised wallets?\n-------------------------------\n\nHere the solutions being deployed, planned, and proposed are harmful,\nand even represent serious threats to Bitcoin's decentralization.\n\n\nConfidence factors\n------------------\n\nMany services such as BlockCypher² have attempted to predict the\nprobability that unconfirmed transactions will be mined, often\nguaranteeing merchants payment³ even in the event of a double-spend. The\nkey component of these predictions is to sybil attack the P2P network as\na whole, connecting to as many nodes as possible to measure transaction\npropagation. Additionally these services connect to pools directly via\nthe getblocktemplate protocol, repeatedly downloading via GBT the lists\nof transactions in the to-be-mined blocks to determine what transactions\nminers are attempting to mine.\n\nNone of these measures scale, wasting significant network and miner\nresources; in one instance a sybil attack by Chainalysis even completely\nblocked the users of the SPV wallet Breadwallet⁴ from accessing the\nnetwork. These measures also don't work very well, giving double-spend\nattackers incentives to sybil attack miners themselves.\n\n\nTransaction processing contracts with miners\n--------------------------------------------\n\nThe next step after measuring propagation fails is to contract with\nminers directly, signing contracts with as much of the hashing power as\npossible to get the transactions they want mined and double-spends\nrejected. The miners/pools would then provide an authenticated API\nendpoint for exclusive use of this service that would allow the service\nto add and remove specific transactions to the mempool on demand.\n\nThere's a number of serious problems with this:\n\n1) Mining contracts can be used to double-spend\n\n...even when they're being used \"honestly\".\n\nSuppose Alice is a merchant using CoinPayCypher, who has contracts with\n75% of the hashing power. Bob, another merchant, meanwhile uses a\ndecentralized Bitcoin Core backend for payments to his website.\n\nMallory wants to double-spend Bob's to buy his expensive products. He\ncan do this by creating a transaction, tx1, that pays Alice, followed by\na second transaction, tx2, that pays Bob. In any circumstance when\nMallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,\nthe chance of Malory's double-spend succeeding becomes ~75% because\nCoinPayCypher's contracts with mining ensure the transaction paying\nAlice will get mined.\n\nOf course, dishonest use and/or compromise makes double-spending\ntrivial: Malory can use the API credentials to ask miners to reject\nBob's payment at any time.\n\n\n2) They still don't work, without 51% attacking other miners\n\nEven if CoinPayCypher has 75% of the hashing power on contract, that's\nstill a potentially 75% chance of being double-spent. The 25% of miners\nwho haven't signed contracts have no _decentralized_ way of ensuring\nthey don't create blocks with double-spends, let alone at low cost. If\nthose miners won't or can't sign contracts with CoinPayCypher the only\nnext step available is to reject their blocks entirely.\n\n\n3) Legal contracts give the advantage to non-anonymous miners in\n   Western jurisdictions\n\nSuppose CoinPayCypher is a US company, and you're a miner with 1%\nhashing power located in northern China. The barriers to you succesfully\nnegotiating a contract with CoinPayCypher are significant. You don't\nspeak the same langauge, you're in a completely different jurisdiction\nso enforcing the legal contract is difficult, and being just 1%,\nCoinPayCypher sees you as insignificant.\n\nWho's going to get the profitable hashing power contracts first, if at\nall? Your English speaking competitors in the west. This is inherently a\npressure towards centralization of mining.\n\n\nWhy isn't this being announced on the bitcoin-security list first?\n------------------------------------------------------------------\n\nI've had repeated discussions with services vulnerable to double-spends;\nthey have been made well aware of the risk they're taking. If they've\nfollowed my own and others' advice they'll at minimum have constant\nmonitoring of the rate of double-spends both on their own services and\non the P2P network in general.\n\nIf you choose to take a risk you should accept the consequences.\n\n\nHow do I actually use full RBF?\n-------------------------------\n\nFirst get the full-RBF patch to v0.10.2:\n\n    https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2\n\nThe above implementation of RBF includes additional code to find and\npreferentially connect to other RBF nodes, as well as Bitcoin XT nodes.\nSecondly, try out my replace-by-fee-tools at:\n\n    https://github.com/petertodd/replace-by-fee-tools\n\nYou can watch double-spends on the network here:\n\n    http://respends.thinlink.com/\n\n\nReferences\n----------\n\n1) \"Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel\n    variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet\",\n   Peter Todd, May 23rd 2015, Bitcoin-development mailing list,\n   http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html\n\n2) \"From Zero to Hero: Bitcoin Transactions in 8 Seconds\",\n   June 2nd, 2014, Erik Voorhees,\n   https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734\n\n3) Coinbase Merchant API, Accessed Jun 19th 2015,\n   https://developers.coinbase.com/docs/merchants/callbacks#confirmations\n\n4) \"Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network\",\n   March 14th 2015, Grace Caffyn, Coindesk,\n   http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/\n\n5) \"First-Seen-Safe Replace-by-Fee\",\n   May 25th 2015, Peter Todd, Bitcoin-development mailing list,\n   http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html\n\n6) \"Cost savings by using replace-by-fee, 30-90%\",\n   May 25th 2015, Peter Todd, Bitcoin-development mailing list,\n   http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html\n\n7) \"Tampering with the Delivery of Blocks and Transactions in Bitcoin\",\n    Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,\n    Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,\n    http://eprint.iacr.org/2015/578\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/fa3a7c7a/attachment.sig\u003e"}