summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChun Wang <1240902@gmail.com>2015-06-19 21:37:49 +0800
committerbitcoindev <bitcoindev@gnusha.org>2015-06-19 13:37:57 +0000
commit300fc7e611dd6ac39d1433d3d1caae5e2bc45ccd (patch)
treed060a01d4e5f4a1d706b31c6a05bf94078671ef0
parentee61a7c257903983257b55b2fecba35ebc0584ab (diff)
downloadpi-bitcoindev-300fc7e611dd6ac39d1433d3d1caae5e2bc45ccd.tar.gz
pi-bitcoindev-300fc7e611dd6ac39d1433d3d1caae5e2bc45ccd.zip
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
-rw-r--r--e7/1b6dd9fea0f17e59e7a129679f828d59699210368
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
+>
+
+