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