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)
Subject: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
Precedence: list


--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--