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 > >