Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-29 📝 Original message:Gregory: Please assign a ...
📅 Original date posted:2015-06-29
📝 Original message:Gregory: Please assign a BIP #
https://github.com/petertodd/bips/blob/bip-full-rbf-deadline/bip-full-rbf-deadline.mediawiki
<pre>
BIP: ??
Title: Full Replace-by-Fee Deployment Schedule
Author: Peter Todd <pete at petertodd.org>
Status: Draft
Type: Standards Track
Created: 2015-06-29
</pre>
==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.
--
'peter'[:-1]@petertodd.org
000000000000000002b9facd4d17c9e3f1f494f9336f7dc5dae35d8918852890
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150629/ebb07fc1/attachment.sig>;
📝 Original message:Gregory: Please assign a BIP #
https://github.com/petertodd/bips/blob/bip-full-rbf-deadline/bip-full-rbf-deadline.mediawiki
<pre>
BIP: ??
Title: Full Replace-by-Fee Deployment Schedule
Author: Peter Todd <pete at petertodd.org>
Status: Draft
Type: Standards Track
Created: 2015-06-29
</pre>
==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.
--
'peter'[:-1]@petertodd.org
000000000000000002b9facd4d17c9e3f1f494f9336f7dc5dae35d8918852890
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150629/ebb07fc1/attachment.sig>;