From 540e30bdfc085a98a19d1f8e59b951400a16ee3c Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 29 Jun 2015 01:01:07 -0400 Subject: [PATCH 1/3] First draft --- bip-full-rbf-deadline.mediawiki | 97 +++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 bip-full-rbf-deadline.mediawiki diff --git a/bip-full-rbf-deadline.mediawiki b/bip-full-rbf-deadline.mediawiki new file mode 100644 index 0000000000..e815d3a098 --- /dev/null +++ b/bip-full-rbf-deadline.mediawiki @@ -0,0 +1,97 @@ +
+  BIP: ??
+  Title: Full Replace-by-Fee Deployment Schedule
+  Author: Peter Todd 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-06-29
+
+ +==Summary== + +This BIP proposes a deployment schedule for full replace-by-fee (full-RBF) +functionality, with an automatic activation of Tuesday April 5th, 2016, at 3pm +UTC upon which supporting relay nodes and miners will enable full-RBF mempool +behavior on mainnet. Prior to the activation deadline supporting nodes and +miners will support first-seen-safe(1) replace-by-fee (FSS-RBF) mempool behavior. + + +==Motivation== + +Full-RBF has significant efficiency advantages(2) over alternatives such as +FSS-RBF and Child-Pays-For-Parent for a wide variety of common transaction +patterns such as fee-bumping and multiple sequential payments, as well as smart +contract protocols such as payment channels and auctions. Miner support would +let the wider Bitcoin community use the blockchain more efficiently, supporting +more transactions per second in less blockchain space. + +While full-RBF does allow users to "undo" transactions after they have been +sent, the ability of decentralized wallets to protect users from double-spends +has proven to be near-zero.(3) Centralized services have had some success in +doing so, albeit at the cost of having to sybil attack the network, a strategy +that cannot scale to more than a small handful of payment processing +companies.(3) + +Even then success is not assured. Worryingly large payment providers have shown +willingness(4) to consider extreme measures such as entering into legal +contracts directly with large miners to ensure their transactions get mined. +This is a significant centralization risk and it is not practical or even +possible for small miners to enter into these contracts, leading to a situation +where moving your hashing power to a larger pool will result in higher profits +from hashing power contracts; if these payment providers secure a majority of +hashing power with these contracts inevitably there will be a temptation to +kick non-compliant miners off the network entirely with a 51% attack. + +It does not make sense for the whole Bitcoin community to incur higher +transaction costs, sybil attacks, and centralization risk for the sake of a +small handful of companies. However an orderly, planned, upgrade is still +desirable. + + +==Implementation== + +As full-RBF usage patterns, unlike first-seen-dependent zeroconf, does not +depend on mempool syncronization this BIP won't specify detailed relay node +behavior. However the following implementation is reasonable and well-tested +with considerations such as DoS attacks taken into account: + + https://github.com/bitcoin/bitcoin/pull/6352 + +To maximize engineer availability the deadline date was chosen to be towards, +but not at, the start of the week, and away from any public holidays. 3pm UTC +was chosen as a compromise between Pacific West Coast and European timezones; +miners in the Asian timezones may choose to manually set their exact switchover +date a few hours ahead with little risk to themselves. Nine months into the +future was chosen on the basis of allowing time for affected companies to plan +for the upgrade, without pushing the upgrade unnecessarily far into the future. + + +==Credits== + +Thanks goes to Jeff Garzik for suggesting the idea of a full-RBF deployment +deadline. + + +==References== + +1) "First-Seen-Safe Replace-by-Fee", +Peter Todd, Bitcoin-development mailing list, May 25th 2015, +http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html + +2) "Cost savings by using replace-by-fee, 30-90%", +Peter Todd, Bitcoin-development mailing list, May 25th 2015, +http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07813.html + +3) "F2Pool has enabled full replace-by-fee", +Peter Todd, Bitcoin-development mailing list, June 19th 2015, +http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08422.html + +4) "F2Pool has enabled full replace-by-fee", +Adrian Macneil, Director of Engineering, Coinbase, +Bitcoin-development mailing list, June 19th 2015, +http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08443.html + +==Copyright== + +This document is placed in the public domain. + From b8faf48b27746c0a17f054d2cd79eed0b8024375 Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 29 Jun 2015 22:32:19 -0400 Subject: [PATCH 2/3] wording --- bip-full-rbf-deadline.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-full-rbf-deadline.mediawiki b/bip-full-rbf-deadline.mediawiki index e815d3a098..a4f9011663 100644 --- a/bip-full-rbf-deadline.mediawiki +++ b/bip-full-rbf-deadline.mediawiki @@ -35,7 +35,7 @@ companies.(3) Even then success is not assured. Worryingly large payment providers have shown willingness(4) to consider extreme measures such as entering into legal contracts directly with large miners to ensure their transactions get mined. -This is a significant centralization risk and it is not practical or even +This is a significant centralization risk as it is not practical or even possible for small miners to enter into these contracts, leading to a situation where moving your hashing power to a larger pool will result in higher profits from hashing power contracts; if these payment providers secure a majority of From 1b1000b63153af18c9fd81e091af4e9e34691ba3 Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Mon, 29 Jun 2015 22:33:57 -0400 Subject: [PATCH 3/3] Change mailing list links to new archive --- bip-full-rbf-deadline.mediawiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bip-full-rbf-deadline.mediawiki b/bip-full-rbf-deadline.mediawiki index a4f9011663..8e98388fac 100644 --- a/bip-full-rbf-deadline.mediawiki +++ b/bip-full-rbf-deadline.mediawiki @@ -76,20 +76,20 @@ deadline. 1) "First-Seen-Safe Replace-by-Fee", Peter Todd, Bitcoin-development mailing list, May 25th 2015, -http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html +http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html 2) "Cost savings by using replace-by-fee, 30-90%", Peter Todd, Bitcoin-development mailing list, May 25th 2015, -http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07813.html +http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008232.html 3) "F2Pool has enabled full replace-by-fee", Peter Todd, Bitcoin-development mailing list, June 19th 2015, -http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08422.html +http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008843.html 4) "F2Pool has enabled full replace-by-fee", Adrian Macneil, Director of Engineering, Coinbase, Bitcoin-development mailing list, June 19th 2015, -http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08443.html +http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008868.html ==Copyright==