Discussion:
BIP: Full Replace-by-Fee deployment schedule
(too old to reply)
Peter Todd
2015-06-29 05:07:26 UTC
Permalink
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.
--
'peter'[:-1]@petertodd.org
000000000000000002b9facd4d17c9e3f1f494f9336f7dc5dae35d8918852890
Luke Dashjr
2015-06-29 05:40:25 UTC
Permalink
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
2015-06-29 05:43:13 UTC
Permalink
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
2015-06-29 05:51:55 UTC
Permalink
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
2015-06-29 05:56:59 UTC
Permalink
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'[:-1]@petertodd.org
00000000000000000ffad4a87861689c067f5dd3b98b84d8096572c163aa913a
Peter Todd
2015-06-29 05:53:15 UTC
Permalink
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.
--
'peter'[:-1]@petertodd.org
00000000000000000ffad4a87861689c067f5dd3b98b84d8096572c163aa913a
Luke Dashjr
2015-06-29 06:00:49 UTC
Permalink
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
2015-06-29 06:16:41 UTC
Permalink
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
2015-06-30 00:21:35 UTC
Permalink
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
2015-06-30 00:51:58 UTC
Permalink
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
2015-06-30 01:00:11 UTC
Permalink
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
2015-06-30 01:10:23 UTC
Permalink
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
2015-06-30 01:18:01 UTC
Permalink
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
2015-06-30 01:37:36 UTC
Permalink
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
--
'peter'[:-1]@petertodd.org
00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
Adam Back
2015-06-30 13:12:52 UTC
Permalink
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
2015-06-30 13:49:51 UTC
Permalink
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
2015-06-30 14:53:09 UTC
Permalink
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.
--
'peter'[:-1]@petertodd.org
00000000000000000c51793e1f2f6b9bd82dd1579b3e4207e70a0aa8fb953c80
David A. Harding
2015-06-30 14:02:13 UTC
Permalink
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
--
David A. Harding
Peter Todd
2015-06-30 16:05:24 UTC
Permalink
Post by 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.
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.
Post by Adam Back
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.
Post by Adam Back
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.
Post by Adam Back
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
Chris Pacia
2015-06-30 18:23:15 UTC
Permalink
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?

Continue reading on narkive:
Loading...