BIP: Full Replace-by-Fee deployment schedule

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.

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

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!

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

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.

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.

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

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.

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.

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.

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").

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.

On 6/29/2015 6:10 PM, Natanael wrote:

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

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

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
>

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?

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

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.

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.

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?