diff options
author | Chun Wang <1240902@gmail.com> | 2015-06-19 21:37:49 +0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-19 13:37:57 +0000 |
commit | 300fc7e611dd6ac39d1433d3d1caae5e2bc45ccd (patch) | |
tree | d060a01d4e5f4a1d706b31c6a05bf94078671ef0 | |
parent | ee61a7c257903983257b55b2fecba35ebc0584ab (diff) | |
download | pi-bitcoindev-300fc7e611dd6ac39d1433d3d1caae5e2bc45ccd.tar.gz pi-bitcoindev-300fc7e611dd6ac39d1433d3d1caae5e2bc45ccd.zip |
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
-rw-r--r-- | e7/1b6dd9fea0f17e59e7a129679f828d59699210 | 368 |
1 files changed, 368 insertions, 0 deletions
diff --git a/e7/1b6dd9fea0f17e59e7a129679f828d59699210 b/e7/1b6dd9fea0f17e59e7a129679f828d59699210 new file mode 100644 index 000000000..614cffb3d --- /dev/null +++ b/e7/1b6dd9fea0f17e59e7a129679f828d59699210 @@ -0,0 +1,368 @@ +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 <bitcoin-development@lists.sourceforge.net>; + 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: <CABHVRKR7bXfDX0_frAv_Ph4Saz3SXwXeZae1DEokorvekPeinw@mail.gmail.com> +References: <20150619103959.GA32315@savin.petertodd.org> + <CABHVRKR7bXfDX0_frAv_Ph4Saz3SXwXeZae1DEokorvekPeinw@mail.gmail.com> +Date: Fri, 19 Jun 2015 21:37:49 +0800 +Message-ID: <CAFzgq-wgHAdPnW5omvcP6OfYbCAh3op+mAYtuzwk188AOZr2QA@mail.gmail.com> +From: Chun Wang <1240902@gmail.com> +To: Stephen Morse <stephencalebmorse@gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 +<stephencalebmorse@gmail.com> 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 <pete@petertodd.org> 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 +> + + |