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