* [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
@ 2015-06-29 5:07 Peter Todd
2015-06-29 5:40 ` Luke Dashjr
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Peter Todd @ 2015-06-29 5:07 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4580 bytes --]
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@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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:07 [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule Peter Todd
@ 2015-06-29 5:40 ` Luke Dashjr
2015-06-29 5:43 ` Gregory Maxwell
2015-06-29 6:16 ` sickpig
2015-06-30 0:21 ` Tom Harding
2 siblings, 1 reply; 20+ messages in thread
From: Luke Dashjr @ 2015-06-29 5:40 UTC (permalink / raw)
To: bitcoin-dev
On Monday, June 29, 2015 5:07:26 AM Peter Todd wrote:
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:40 ` Luke Dashjr
@ 2015-06-29 5:43 ` Gregory Maxwell
2015-06-29 5:51 ` Luke Dashjr
2015-06-29 5:53 ` Peter Todd
0 siblings, 2 replies; 20+ messages in thread
From: Gregory Maxwell @ 2015-06-29 5:43 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
On Mon, Jun 29, 2015 at 5:40 AM, Luke Dashjr <luke@dashjr•org> wrote:
> 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!
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:43 ` Gregory Maxwell
@ 2015-06-29 5:51 ` Luke Dashjr
2015-06-29 5:56 ` Peter Todd
2015-06-29 5:53 ` Peter Todd
1 sibling, 1 reply; 20+ messages in thread
From: Luke Dashjr @ 2015-06-29 5:51 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-dev
On Monday, June 29, 2015 5:43:13 AM Gregory Maxwell wrote:
> On Mon, Jun 29, 2015 at 5:40 AM, Luke Dashjr <luke@dashjr•org> wrote:
> > 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:51 ` Luke Dashjr
@ 2015-06-29 5:56 ` Peter Todd
0 siblings, 0 replies; 20+ messages in thread
From: Peter Todd @ 2015-06-29 5:56 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
On Mon, Jun 29, 2015 at 05:51:55AM +0000, Luke Dashjr wrote:
> On Monday, June 29, 2015 5:43:13 AM Gregory Maxwell wrote:
> > On Mon, Jun 29, 2015 at 5:40 AM, Luke Dashjr <luke@dashjr•org> wrote:
> > > 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'[:-1]@petertodd.org
00000000000000000ffad4a87861689c067f5dd3b98b84d8096572c163aa913a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:43 ` Gregory Maxwell
2015-06-29 5:51 ` Luke Dashjr
@ 2015-06-29 5:53 ` Peter Todd
2015-06-29 6:00 ` Luke Dashjr
1 sibling, 1 reply; 20+ messages in thread
From: Peter Todd @ 2015-06-29 5:53 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
On Mon, Jun 29, 2015 at 05:43:13AM +0000, Gregory Maxwell wrote:
> On Mon, Jun 29, 2015 at 5:40 AM, Luke Dashjr <luke@dashjr•org> wrote:
> > 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.
--
'peter'[:-1]@petertodd.org
00000000000000000ffad4a87861689c067f5dd3b98b84d8096572c163aa913a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:53 ` Peter Todd
@ 2015-06-29 6:00 ` Luke Dashjr
0 siblings, 0 replies; 20+ messages in thread
From: Luke Dashjr @ 2015-06-29 6:00 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
On Monday, June 29, 2015 5:53:15 AM Peter Todd wrote:
> On Mon, Jun 29, 2015 at 05:43:13AM +0000, Gregory Maxwell wrote:
> > On Mon, Jun 29, 2015 at 5:40 AM, Luke Dashjr <luke@dashjr•org> wrote:
> > > 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.
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:07 [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule Peter Todd
2015-06-29 5:40 ` Luke Dashjr
@ 2015-06-29 6:16 ` sickpig
2015-06-30 0:21 ` Tom Harding
2 siblings, 0 replies; 20+ messages in thread
From: sickpig @ 2015-06-29 6:16 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
Hi Peter,
> ==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
just a minor nit pick, you should update "References" links using the new
mailing list archive.
[-- Attachment #2: Type: text/html, Size: 1587 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-29 5:07 [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule Peter Todd
2015-06-29 5:40 ` Luke Dashjr
2015-06-29 6:16 ` sickpig
@ 2015-06-30 0:21 ` Tom Harding
2015-06-30 0:51 ` Natanael
2015-06-30 1:37 ` Peter Todd
2 siblings, 2 replies; 20+ messages in thread
From: Tom Harding @ 2015-06-30 0:21 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
On 6/28/2015 10:07 PM, Peter Todd wrote:
> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 0:21 ` Tom Harding
@ 2015-06-30 0:51 ` Natanael
2015-06-30 1:00 ` Tom Harding
2015-06-30 1:37 ` Peter Todd
1 sibling, 1 reply; 20+ messages in thread
From: Natanael @ 2015-06-30 0:51 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]
Den 30 jun 2015 02:21 skrev "Tom Harding" <tomh@thinlink•com>:
>
> On 6/28/2015 10:07 PM, Peter Todd wrote:
>>
>> 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.
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.
[-- Attachment #2: Type: text/html, Size: 2642 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 0:51 ` Natanael
@ 2015-06-30 1:00 ` Tom Harding
2015-06-30 1:10 ` Natanael
0 siblings, 1 reply; 20+ messages in thread
From: Tom Harding @ 2015-06-30 1:00 UTC (permalink / raw)
To: Natanael; +Cc: bitcoin-dev
On 6/29/2015 5:51 PM, Natanael wrote:
> 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").
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 1:00 ` Tom Harding
@ 2015-06-30 1:10 ` Natanael
2015-06-30 1:18 ` Tom Harding
0 siblings, 1 reply; 20+ messages in thread
From: Natanael @ 2015-06-30 1:10 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
Den 30 jun 2015 03:00 skrev "Tom Harding" <tomh@thinlink•com>:
>
> On 6/29/2015 5:51 PM, Natanael wrote:
>>
>> 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").
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.
[-- Attachment #2: Type: text/html, Size: 1613 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 0:21 ` Tom Harding
2015-06-30 0:51 ` Natanael
@ 2015-06-30 1:37 ` Peter Todd
2015-06-30 13:12 ` Adam Back
1 sibling, 1 reply; 20+ messages in thread
From: Peter Todd @ 2015-06-30 1:37 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]
On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote:
> On 6/28/2015 10:07 PM, Peter Todd wrote:
> >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
--
'peter'[:-1]@petertodd.org
00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 1:37 ` Peter Todd
@ 2015-06-30 13:12 ` Adam Back
2015-06-30 13:49 ` Chris Pacia
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Adam Back @ 2015-06-30 13:12 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
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
On 30 June 2015 at 03:37, Peter Todd <pete@petertodd•org> wrote:
> On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote:
>> On 6/28/2015 10:07 PM, Peter Todd wrote:
>> >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
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 13:12 ` Adam Back
@ 2015-06-30 13:49 ` Chris Pacia
2015-06-30 14:53 ` Peter Todd
2015-06-30 14:02 ` David A. Harding
2015-06-30 16:05 ` Peter Todd
2 siblings, 1 reply; 20+ messages in thread
From: Chris Pacia @ 2015-06-30 13:49 UTC (permalink / raw)
To: bitcoin-dev
On 06/30/2015 09:12 AM, Adam Back wrote:
> 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?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 13:49 ` Chris Pacia
@ 2015-06-30 14:53 ` Peter Todd
0 siblings, 0 replies; 20+ messages in thread
From: Peter Todd @ 2015-06-30 14:53 UTC (permalink / raw)
To: Chris Pacia; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
On Tue, Jun 30, 2015 at 09:49:51AM -0400, Chris Pacia wrote:
>
>
> On 06/30/2015 09:12 AM, Adam Back wrote:
> > 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.
--
'peter'[:-1]@petertodd.org
00000000000000000c51793e1f2f6b9bd82dd1579b3e4207e70a0aa8fb953c80
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 13:12 ` Adam Back
2015-06-30 13:49 ` Chris Pacia
@ 2015-06-30 14:02 ` David A. Harding
2015-06-30 16:05 ` Peter Todd
2 siblings, 0 replies; 20+ messages in thread
From: David A. Harding @ 2015-06-30 14:02 UTC (permalink / raw)
To: Adam Back; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
On Tue, Jun 30, 2015 at 03:12:52PM +0200, Adam Back wrote:
> 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
--
David A. Harding
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 13:12 ` Adam Back
2015-06-30 13:49 ` Chris Pacia
2015-06-30 14:02 ` David A. Harding
@ 2015-06-30 16:05 ` Peter Todd
2015-06-30 18:23 ` Chris Pacia
2 siblings, 1 reply; 20+ messages in thread
From: Peter Todd @ 2015-06-30 16:05 UTC (permalink / raw)
To: Adam Back; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4359 bytes --]
On Tue, Jun 30, 2015 at 03:12:52PM +0200, Adam Back wrote:
> 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.
Well, as you know I have good reason to believe those contracts are
being actively worked on right now. I've been talking about this issue
for something like two years now, and rather than seeing a shift away
from use of zeroconf, we're seeing new services adopting it, always
large, centralized, startups in the payment space. Meanwhile the story
for decentralized wallets is if anything even worse, and most such
wallets don't even have code to detect double-spends at all.
From the point of view of large companies like Coinbase, getting hashing
power contracts and sybil attacking the network is relatively easy. Why
would they invest in genuine improvements when they can take the easy
way out? Especially when the easy way is something their smaller
competitors simply have no access too? Working on those contracts now
only makes sense, especially as the reliability of the P2P network in
providing zeroconf guarantees continues to decline as transaction volume
increases, and uniformity of nodes decreases.
By acting sooner rather than later in adopting full-RBF I think we have
a shot at changing the direction of the industry; if we wait I think we
stand a real chance of that dangerous infrastructure being put into
place. Equally, when you ask who is benefiting from the status quo, it
isn't decentralized wallets, but a small number of centralized startups
who have an advantage that the former can't match.
> 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.
You know, if the status quo didn't have the downsides I mention above,
I'd probably agree with you on that point. But the risks outweigh it
IMO.
> 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.
Note how relaying proof of double-spent status is only useful if you can
do something about it; the only method available without a scripting
language soft-fork is the scorched earth concept, which ironically
relies on full-RBF.
> Any thoughts on the simplest way to support an opt-in version of full-RBF?
I'd suggest using nSequence for that purpose by defining non-maxint
nSequence as allowing RBF. (as well as non-maxint - 1 for nLockTime
usage to discourage fee sniping) Mark Friedenbach's sequence number BIP
is going to make use of transaction replacement anyway after all, so
doing that would be forward-compatible with it.
--
'peter'[:-1]@petertodd.org
0000000000000000129dec64f63611dc737b87331bb165740fb5552a92833a12
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
2015-06-30 16:05 ` Peter Todd
@ 2015-06-30 18:23 ` Chris Pacia
0 siblings, 0 replies; 20+ messages in thread
From: Chris Pacia @ 2015-06-30 18:23 UTC (permalink / raw)
To: bitcoin-dev
On 06/30/2015 12:05 PM, Peter Todd wrote:
> 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?
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-06-30 18:23 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-29 5:07 [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule Peter Todd
2015-06-29 5:40 ` Luke Dashjr
2015-06-29 5:43 ` Gregory Maxwell
2015-06-29 5:51 ` Luke Dashjr
2015-06-29 5:56 ` Peter Todd
2015-06-29 5:53 ` Peter Todd
2015-06-29 6:00 ` Luke Dashjr
2015-06-29 6:16 ` sickpig
2015-06-30 0:21 ` Tom Harding
2015-06-30 0:51 ` Natanael
2015-06-30 1:00 ` Tom Harding
2015-06-30 1:10 ` Natanael
2015-06-30 1:18 ` Tom Harding
2015-06-30 1:37 ` Peter Todd
2015-06-30 13:12 ` Adam Back
2015-06-30 13:49 ` Chris Pacia
2015-06-30 14:53 ` Peter Todd
2015-06-30 14:02 ` David A. Harding
2015-06-30 16:05 ` Peter Todd
2015-06-30 18:23 ` Chris Pacia
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox