[bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule

[Peter Todd]

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 <***@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-***@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-***@lists.sourceforge.net/msg08443.html

==Copyright==

This document is placed in the public domain.

[Luke Dashjr]

Post by Peter Todd
Gregory: Please assign a BIP #
https://github.com/petertodd/bips/blob/bip-full-rbf-deadline/bip-full-rbf-d
eadline.mediawiki

Policy is node/miner fiat and not the domain of BIPs.

Luke

[Gregory Maxwell]

Post by Luke Dashjr
Policy is node/miner fiat and not the domain of BIPs.

Even accepting the premise that policy is pure local fiat, the
conclusion doesn't follow for me. BIPs about best practices or
especially anything where interop or coordination are, I think,
reasonable uses of the process.

E.g. you might want to know what other kinds of policy are in use if
you're to have any hope of authoring transactions that work at all!

[Luke Dashjr]

Post by Gregory Maxwell

Post by Luke Dashjr
Policy is node/miner fiat and not the domain of BIPs.

Even accepting the premise that policy is pure local fiat, the
conclusion doesn't follow for me. BIPs about best practices or
especially anything where interop or coordination are, I think,
reasonable uses of the process.
E.g. you might want to know what other kinds of policy are in use if
you're to have any hope of authoring transactions that work at all!

Then we are to start issuing a new BIP for every node's policy? This has no
end - though it might make sense for an independent and updated database.
Mixing protocol standards with policy suggestions makes a very risky situation
where one can potentially hold a miner liable for not enforcing the BIP; ie,
government regulation of Bitcoin itself. I don't think most people want to go
there...

Luke

[Peter Todd]

Post by Luke Dashjr

Post by Gregory Maxwell

Post by Luke Dashjr
Policy is node/miner fiat and not the domain of BIPs.

Even accepting the premise that policy is pure local fiat, the
conclusion doesn't follow for me. BIPs about best practices or
especially anything where interop or coordination are, I think,
reasonable uses of the process.
E.g. you might want to know what other kinds of policy are in use if
you're to have any hope of authoring transactions that work at all!

Then we are to start issuing a new BIP for every node's policy? This has no
end - though it might make sense for an independent and updated database.
Mixing protocol standards with policy suggestions makes a very risky situation
where one can potentially hold a miner liable for not enforcing the BIP; ie,
government regulation of Bitcoin itself. I don't think most people want to go
there...

Remember that one of the goals of full-RBF is to explicitly reject the
idea that miners should have any obligation with regard to what they're
mining. I perhaps should say that explicitly in my BIP proposal; I say
it implicitly by pointing out how the BIP *doesn't* define an exact
standard, but rather only an suggests an implementation as a starting
point.

[Peter Todd]

Post by Gregory Maxwell

Post by Luke Dashjr
Policy is node/miner fiat and not the domain of BIPs.

Even accepting the premise that policy is pure local fiat, the
conclusion doesn't follow for me. BIPs about best practices or
especially anything where interop or coordination are, I think,
reasonable uses of the process.
E.g. you might want to know what other kinds of policy are in use if
you're to have any hope of authoring transactions that work at all!

For example, consider Luke-Jr's own BIP19, M-of-N Standard Transactions,
a non-consensus-critical suggested policy change!

https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki

Anyway, full-RBF has significant impacts for wallet authors and many
other stakeholders. At minimum it changes how you will want to author
and (re)author transactions, much like BIP19 does.

[Luke Dashjr]

Post by Peter Todd

Post by Gregory Maxwell

Post by Luke Dashjr
Policy is node/miner fiat and not the domain of BIPs.

Even accepting the premise that policy is pure local fiat, the
conclusion doesn't follow for me. BIPs about best practices or
especially anything where interop or coordination are, I think,
reasonable uses of the process.
E.g. you might want to know what other kinds of policy are in use if
you're to have any hope of authoring transactions that work at all!

For example, consider Luke-Jr's own BIP19, M-of-N Standard Transactions,
a non-consensus-critical suggested policy change!
https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki

BIP 19 does not explicitly purport to directly change policy. It defines a
standard way of assembling multisig transactions.

Post by Peter Todd
Anyway, full-RBF has significant impacts for wallet authors and many
other stakeholders. At minimum it changes how you will want to author
and (re)author transactions, much like BIP19 does.

This is omitted from the BIP (in fact, it doesn't even have a Specification
section!). No objections to a BIP specifying standards to use for
authoring/modifying transactions for RBF, but it should leave out policy (or
at least constrain it to a strictly non-normative section.

Luke

[s***@gmail.com]

Hi Peter,

Post by Peter Todd
==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

Post by Peter Todd
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

Post by Peter Todd
3) "F2Pool has enabled full replace-by-fee",
Peter Todd, Bitcoin-development mailing list, June 19th 2015,
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-***@lists.sourceforge.net/msg08443.html

just a minor nit pick, you should update "References" links using the new
mailing list archive.

[Tom Harding]

Post by Peter Todd
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.

Your incomprehensible meddling with successful usage patterns threatens
to have unintended consequences directly in opposition to your own
stated goal of decentralization. And yet you persist.

As we deliberately break things and turn the P2P network into a
completely unpredictable hodge-podge of relay policies, we should expect
many more participants to bypass the P2P network entirely.

Many of the pieces are already in place.

If we wanted the P2P network to have more predicable behavior, it would
be possible for nodes to provide incentives to their neighbors. For
example, if you had a pair of nodes, you could test your peers to see
that they actually do relay "standard" transactions. This would have
emergent usability benefits for the P2P network as a whole.

[Natanael]

Post by Tom Harding

Post by Peter Todd
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.

Your incomprehensible meddling with successful usage patterns threatens

to have unintended consequences directly in opposition to your own stated
goal of decentralization. And yet you persist.

Post by Tom Harding
As we deliberately break things and turn the P2P network into a

completely unpredictable hodge-podge of relay policies, we should expect
many more participants to bypass the P2P network entirely.

What you are asking for is TSA style reactive security and unverifiable and
fundamentally untrustable security mechanisms, rejecting proactive security
on the grounds that it is inconvenient.

What you ask to see implemented will trivially fall to a sybil attack. It
isn't securable. It is running on the honor system exclusively. It will be
attacked, it will fail, losses will be had, the attackers will walk away
with embarrassingly large sums.

You want verifiable behavior? Incentives to tell the truth? Incentives to
be consistent? Multisignature notaries (Greenaddress.it), payment channel
based hub-and-spokes (LN, Stroem), etc... Trusting the P2P network is
futile. You need one accountable party that is actually capable of
enforcing the behavior you ask for, one that can build a reputation over
time - the P2P nodes you wish to hold accountable are on the other hand
powerless to stop an actual attack, their reputations are therefore
meaningless and irrelevant. Multisignature notaries aren't, as they can
stop an attack, and they can be sued for breach of contract if they don't -
neither of those applies to P2P nodes.

[Tom Harding]

Post by Natanael
What you ask to see implemented will trivially fall to a sybil attack.
It isn't securable. It is running on the honor system exclusively. It
will be attacked, it will fail, losses will be had, the attackers will
walk away with embarrassingly large sums.

Oh please. Checking that a node does relay something is not much
different than banning it for relaying garbage.

It just happens to require that you have two nodes and coordinate them
somehow. I didn't offer a complete design, don't claim magical
properties, and certainly didn't mean to imply that nodes passing a test
could be trusted (as you suggest with your "accountable parties").

[Natanael]

Post by Tom Harding

Post by Natanael
What you ask to see implemented will trivially fall to a sybil attack.

It isn't securable. It is running on the honor system exclusively. It will
be attacked, it will fail, losses will be had, the attackers will walk away
with embarrassingly large sums.

Post by Tom Harding
Oh please. Checking that a node does relay something is not much

different than banning it for relaying garbage.

Post by Tom Harding
It just happens to require that you have two nodes and coordinate them

somehow. I didn't offer a complete design, don't claim magical properties,
and certainly didn't mean to imply that nodes passing a test could be
trusted (as you suggest with your "accountable parties").

But the check means nothing at all to you since no information which you
can learn from doing so can be trusted for use in decision making of any
kind, so why do it? Unless you pay for hosting of that particular node
which you test, you have no reason to care for any reason other than simple
statistics.

The claims I made is based on simple economic analysis - if *to be able to
attack* first requires effort and risk that exceed the payoff, you're
unlikely to try. Being legally accountable and identified in advance and
having to build reputation before being trusted with attack-worthy sums is
strongly discouraging.

[Tom Harding]

Post by Natanael
you have no reason to care

Of course I do. I'll boot them and replace them with somebody who will
relay the items I send them. I'm not here to send things into a black
hole taking up one of my connection slots.

[Peter Todd]

This post might be inappropriate. Click to display it.

[Adam Back]

It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.

I think it would be better to deploy full-RBF in an opt-in way and
leave the current default miner & relay policies as is. So for
example a new signature flag or transaction type that is marked as
opting-in waiving the first-seen policy.

In this way we can get a smoother transition for people away from the
first-seen assumption, towards greenaddress (trust based) and
lightning / payment channel solutions. Mid-term the channel and hub
model can provide fast secure 0-confirm transactions, which are
generically not known to be directly and robustly securable via miner
consensus.

As we've seen abruptly stopping the first-seen miner & relay policy is
risky and unpopular and causes people to seek contracts with miners to
retain first-seen. This is itself a bad trend for fungibility for
obvious reasons.

We shouldn't prejudge people's and segment's of business weak-reliance
on first-seen. Some types of payments are generally high trust (known
relationships) or physical stores or very low marginal cost (coffee
marginal cost <10c, sale price > $2 or lower ebook, audio stream etc
as embodied by fremium model). It is not ours to prejudge and kill
their business. It our job to help improve network security however,
so that they do not have to eat a fraud cost. And that is do able
with trust via greenaddress, or without trust (other than
time-preference) via the hub & channel model.

Security maybe incrementally improvable via non-spendable relaying of
proof of double-spent status, and services that try to measure % of
miners by hashrate with assumption of first-seen that have have seen a
given transaction first, though I am not sure such approaches are
robust enough to invest time in vs greenaddress or hub & channel.

Any thoughts on the simplest way to support an opt-in version of full-RBF?

Adam

Post by Peter Todd

Post by Tom Harding

Post by Peter Todd
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.

Your incomprehensible meddling with successful usage patterns
threatens to have unintended consequences directly in opposition to
your own stated goal of decentralization. And yet you persist.
As we deliberately break things and turn the P2P network into a
completely unpredictable hodge-podge of relay policies, we should
expect many more participants to bypass the P2P network entirely.
Many of the pieces are already in place.
If we wanted the P2P network to have more predicable behavior, it
would be possible for nodes to provide incentives to their
neighbors. For example, if you had a pair of nodes, you could test
your peers to see that they actually do relay "standard"
transactions. This would have emergent usability benefits for the
P2P network as a whole.

To be clear, full-RBF is a change that broadens what the P2P network
relays - transactions previously not relayed are now relayed. Under no
circumstance will full-RBF result in transactions *not* being relayed
that previously were relayed. This makes the P2P network more useful
rather than less, as it gives a predictable and uniform method to get
transactions to a wider variety of miners with a wider variety of
policies.
Note how even if no miners ever supported full-RBF, supporting full-RBF
on relay nodes would still be useful to users as it provides an easy and
cost-effective mechanism to rebroadcast transactions. In fact,
supporting full-RBF by default and disabling it if getblocktemplate is
called would be reasonable, if more than a bit of a hack!
In any case, my pull-req lets you set -fullrbfactivationtime=0 as a
simple and easy way to disable full-RBF functionality. Miners and relay
nodes who choose not to support it can easily do so, similar to how
OP_RETURN transactions can be disabled with -datacarrier=0
--
00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Chris Pacia]

Post by Adam Back
It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.

What would be the effect of IBLT on the first seen policy? It seems that
if a miner has to broadcast extra data with his blocks because he's
using full RBF and everyone else is using first-seen then his blocks are
at a disadvantage in terms of propagation. That wouldn't make first-seen
a hard consensus rule, but rather one rational miners are likely to
follow. Or is this effect likely to be minimal?

[Peter Todd]

Post by Chris Pacia

Post by Adam Back
It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.

What would be the effect of IBLT on the first seen policy? It seems that
if a miner has to broadcast extra data with his blocks because he's
using full RBF and everyone else is using first-seen then his blocks are
at a disadvantage in terms of propagation. That wouldn't make first-seen
a hard consensus rule, but rather one rational miners are likely to
follow. Or is this effect likely to be minimal?

The disadvantage can be calculated compensated for by higher fees; if
the disadvantage is so large that the higher fees are unaffordable we're
in big trouble as the guarantees that mempools are in sync are pretty
poor. (why doublespending zeroconf txs is easy!) For instance, that'd
imply that sending two simultaneous transactions will cause profit
losses to all but the largest miners - who are unaffected - and that
upgrades that change IsStandard() will cause profit losses, among many
other problems.

Bitcoin just doesn't work if blocks aren't relayed quickly in the worst
case.

[David A. Harding]

Post by Adam Back
Any thoughts on the simplest way to support an opt-in version of full-RBF?

Bundle it in with BIP62 version-2 (or whatever) transactions.

- As you desire for RBF, the BIP62 transactions are already specified to
be opt-in. Nobody has to use them.

- Although BIP62 transactions only prevent third-party mutation, some
people might wrongly assume that they prevent all mutation---including
double spending.

We need to make it clear that even with BIP62 transactions, signers
can still mutate their own transactions---and what better way to do
that than make BIP62 transactions easier to double spend?

The downside I see is possible further delay of full BIP62. Although, I
guess it could go the other way too by having developers who want RBF
help push BIP62 into production.

-Dave

[Peter Todd]

This post might be inappropriate. Click to display it.

[Chris Pacia]

Post by Peter Todd
Well, as you know I have good reason to believe those contracts are
being actively worked on right now.

Isn't the whole reason they are working on those contracts because a few
miners don't use first-seen in all circumstances as it is? Or as a
corollary, wouldn't full RBF just create that much more incentive for
those type of contracts?