From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <1240902@gmail.com>) id 1Z5wUX-0004XC-2c for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 13:37:57 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.47 as permitted sender) client-ip=74.125.82.47; envelope-from=1240902@gmail.com; helo=mail-wg0-f47.google.com; Received: from mail-wg0-f47.google.com ([74.125.82.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5wUV-0003tu-69 for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 13:37:57 +0000 Received: by wgfq1 with SMTP id q1so43329330wgf.1 for ; Fri, 19 Jun 2015 06:37:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.205.5 with SMTP id lc5mr26435689wjc.74.1434721069157; Fri, 19 Jun 2015 06:37:49 -0700 (PDT) Received: by 10.180.208.69 with HTTP; Fri, 19 Jun 2015 06:37:49 -0700 (PDT) In-Reply-To: References: <20150619103959.GA32315@savin.petertodd.org> Date: Fri, 19 Jun 2015 21:37:49 +0800 Message-ID: From: Chun Wang <1240902@gmail.com> To: Stephen Morse Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (1240902[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (1240902[at]gmail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z5wUV-0003tu-69 Cc: bitcoin-development Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 13:37:57 -0000 Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. On Fri, Jun 19, 2015 at 9:33 PM, Stephen Morse wrote: > It is disappointing that F2Pool would enable full RBF when the safe > alternative, first-seen-safe RBF, is also available, especially since the > fees they would gain by supporting full RBF over FSS RBF would likely be > negligible. Did they consider using FSS RBF instead? > > Best, > Stephen > > On Fri, Jun 19, 2015 at 6:39 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=C2=B9 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=E2=81=B5 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=E2=81=B6) 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=E2=81=B7 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=C2=B2 have attempted to predict the >> probability that unconfirmed transactions will be mined, often >> guaranteeing merchants payment=C2=B3 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=E2=81=B4 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/ms= g07795.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-transactio= ns-in-8-seconds-7c9edcb3b734 >> >> 3) Coinbase Merchant API, Accessed Jun 19th 2015, >> https://developers.coinbase.com/docs/merchants/callbacks#confirmation= s >> >> 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/ms= g07813.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 >> > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >