From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 014C8273
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jun 2015 05:07:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148099.authsmtp.net (outmail148099.authsmtp.net
[62.13.148.99])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C4BAC7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jun 2015 05:07:32 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5T57UOG015376;
Mon, 29 Jun 2015 06:07:30 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5T57R01066085
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 29 Jun 2015 06:07:29 +0100 (BST)
Date: Mon, 29 Jun 2015 01:07:26 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20150629050726.GA502@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: be07ca33-1e1c-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAsUEkAaAgsB AmMbW1JeUFp7WmM7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRll Axl8UhhycQNGcHs+ ZEFrX3MVDhF6chUs
QU1JFDgHNnphaTUa TRJbfgVJcANIexZF O1F6ACIKLxd+BnBw
MRI3O3gLMC1bIS9Y BwscaHwfTA4HEyY4 QAEHEDMzVVYORyg/ MhgrQl4B
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2015 05:07:34 -0000
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Gregory: Please assign a BIP #
https://github.com/petertodd/bips/blob/bip-full-rbf-deadline/bip-full-rbf-d=
eadline.mediawiki
<pre>
BIP: ??
Title: Full Replace-by-Fee Deployment Schedule
Author: Peter Todd <pete@petertodd.org>
Status: Draft
Type: Standards Track
Created: 2015-06-29
</pre>
=3D=3DSummary=3D=3D
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 mempo=
ol
behavior on mainnet. Prior to the activation deadline supporting nodes and
miners will support first-seen-safe(1) replace-by-fee (FSS-RBF) mempool beh=
avior.
=3D=3DMotivation=3D=3D
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 s=
mart
contract protocols such as payment channels and auctions. Miner support wou=
ld
let the wider Bitcoin community use the blockchain more efficiently, suppor=
ting
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-spe=
nds
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 strat=
egy
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 s=
hown
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 situa=
tion
where moving your hashing power to a larger pool will result in higher prof=
its
=66rom hashing power contracts; if these payment providers secure a majorit=
y 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.
=3D=3DImplementation=3D=3D
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 toward=
s,
but not at, the start of the week, and away from any public holidays. 3pm U=
TC
was chosen as a compromise between Pacific West Coast and European timezone=
s;
miners in the Asian timezones may choose to manually set their exact switch=
over
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 p=
lan
for the upgrade, without pushing the upgrade unnecessarily far into the fut=
ure.
=3D=3DCredits=3D=3D
Thanks goes to Jeff Garzik for suggesting the idea of a full-RBF deployment
deadline.
=3D=3DReferences=3D=3D
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/msg=
07829.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/msg=
07813.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/msg08=
422.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/msg08=
443.html
=3D=3DCopyright=3D=3D
This document is placed in the public domain.
--=20
'peter'[:-1]@petertodd.org
000000000000000002b9facd4d17c9e3f1f494f9336f7dc5dae35d8918852890
--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVkNKJXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMmI5ZmFjZDRkMTdjOWUzZjFmNDk0ZjkzMzZmN2RjNWRh
ZTM1ZDg5MTg4NTI4OTAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuQnQf+NMxge0GQW4Dj/TSwB4MwEhFq
Mt1kLoBlWQ+5N8bsGtu83Xs1z+vrSqdAX/SYfCr91QUl3ZF4HEyXMz19mApBWP5y
zyjno4kxFHc+IdupiN/d0ZYhChLlfgP624sBNJ6taTlIdSCV6N6FB7szWBcwsT+h
yA2iXxc5xP/9y/Ru88sX1KvNZTIHOKiusB5L6DPsd4NEOBdWxTtzw8WIdakDdwRl
kTlzmOEqkj/KPmlMBtefOK2b88tz24Y9kQJEJf/jezwTlrBT3IQJS7KuCFTtHxuc
OgEGFno4f6TnRJ4sB2F9h9UsTxPco2jXFtAx9eKR5rVSWR4GnDlFMCGGFrQlww==
=sitE
-----END PGP SIGNATURE-----
--X1bOJ3K7DJ5YkBrT--