Sorry about that, ignore me On Jun 20, 2015 11:11 PM, "Dario Sneidermanis" wrote: > se, lo re putearon a Peter Todd en reddit por esto > On Jun 19, 2015 7:42 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/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 >> >>