BUIP004 (passed A1): RBF/double spending support

[freetrader]

Some means of clearing stuck transactions is very important for any form of smart contract where it is often vital that a transaction is sent before some deadline (usually set in some other time locked transaction). This is true, for example, for all forms of payment channel (including Lightning). Smart contracts of this kind generally won't be using zeroconf so opt-in RBF works fine for that use case, and since it's opt-in, it doesn't affect normal transactions.

I am looking forward to your technical post on this.

Do you know of an exhaustive treatment anywhere on the various causes of stuck transactions and approaches to resolving them?
[doublepost=1451699519,1451698749][/doublepost]

It would be helpful if you provide context for quotes like this. Jeff is talking here about full (non-opt-in) RBF here, which is not what is in Core's 0.12 release, and not what this BUIP is discussing.

I provided context in the form of a link to Peter Todd's original RBF pull request. I suggest you read the title and body of this BUIP again. The topic under discussion is RBF support in BU in general (various options under consideration), and not merely opt-in RBF as Core is implementing in 0.12, which is not yet released and hence its final content not assured.

It would be helpful if you do not try to restrict the discussion to your own field of view.

 

[Peter R]

@Roy Badami

The idea behind "opt-in" RBF is that wallets could mark transactions as "double-spendable" and then nodes that support this RBF would allow these transactions to be double-spent.

I think many of us are opposed to this idea. We would want our nodes to not permit double-spending even if the sender of the transaction asked for it.

 

[Roy Badami]

I'm not sure I understand the relevence of a rejected pull request. You do realise that anyone can submit a pull request? And not to diminish Peter's contributions to Bitcoin, but he's not a Core committer.

As for what's in Core 0.12 - you're right that things could still change, but we do pretty much know what's going to be in there, because Core is now in feature freeze for 0.12. What's in 0.12 is expected to be pretty much what's in github now.

Discussing a switch to turn off a Core feature that won't exist for the foreseeable future (if ever) seems pointless. Opt-in RBF is the only thing that is likely to be in Core in the short term - so the only thing we need to decide now is how we handle that.

 

[Roy Badami]

@Peter R

Well, opt-in RBF only alllows double spending if people are silly enough to accept zeroconf transactions that opt in. Of course, it means wallets and merchants need to be coded to check for this, but at this point that's pretty much a sunk cost.
[doublepost=1451701104][/doublepost]Anyway, I'm going to try and find time to write one proper post on all the issues I see rather than replying further piecemeal - and then once I've done that you can all pick holes in it

 

[solex]

@Roy Badami
I too would welcome your write-up. Great to see you on this forum!
What concerns me is not the technical argument about opt-in RBF, but the social one. There are many business that accept 0-conf simply because they are Bitcoin believers (to varying degrees) who like the concept, its ethos, and are selling a product or service, so will accept BTC just to do something to help it succeed. The social aspect is them hearing that 0-conf is no longer "reliable" and that they might have a payment overridden later. They don't want to check how up-to-date their wallet software is. They might find it simpler to just drop 0-conf acceptance or even Bitcoin acceptance altogether. That is my worry.

 

[Inca]

I personally welcome some dissenting voices to the debate. This is the time to hash out what behaviour we want from BU, and to decide what ideals in the network we are trying to uphold.

I really would like some analysis on how disruptive to network RBF functionality having various % of nodes which do not support relaying of RBF double spend transactions actually is. If we know roughly what proportion of nodes are miners compared with standard nodes, how many connections each node typically has it should be possible to work out how many degrees of separation each node is from miner and model the effect..

 

[Zangelbert Bingledack]

I don't have a strong position on opt-in RBF, but I see some unmentioned considerations on the pro side:

Complete backward compatibility in all aspects and use cases that *anyone anywhere ever* falsely advertized as permanently usable-without-ever-upgrading is quite a restrictive principle.

At some point it's got to be acceptable to expect some level of wallet devs keeping up with developments and merchants keeping their apps updated if they want to use edge cases like 0-conf. Otherwise any false advertizing claim anyone makes becomes a permanent millstone around Bitcoin's neck. Everyone having updated wallets allows opt-in RBF to be totally fine and helpful, correct? My main concern is the slippery slope toward full RBF. However, that is exactly where BU *does* come to the rescue.

Plus, if Core implements opt-in RBF, either no one uses it or some people use it. If no one uses it none of this matters. If some people use it, non-upgrading merchants who rely on 0-conf are going to get burned no matter what BU does.

 

[Zangelbert Bingledack]

Another big one for BU:

First note that the BU paradigm strips Core/etc. devs of consensus-designer status and relegates them to something closer to the role of wallet designers. Then note how things like opt-in RBF vest normal wallet devs (Breadwallet, Mycellium, etc.) with greater responsibility: the wallet becomes more of a trusted interface with Bitcoin than it already is. Merchants will increasingly have to trust their wallet not only to handle funds properly but also to keep them alerted to any needed changes in network behavior and auto-update in response.

In short, BU makes node devs more like wallet devs, and things like opt-in RBF expand the scope of responsibilities of wallet devs. Wallet and node designers are being mooshed together into a service sector of the ecosystem that offers options for interfacing with the consensus Bitcoin system, while the consensus-setting itself is being left to the node operators and miners (for completeness: backed by merchant and exchange acceptance and ultimately by investors).

A division of labor. Specialization. BU + opt-in RBF means Core's thumb gets pulled out of the consensus-setting pie while its lunch gets eaten by the lowly wallet app. Sounds like wallet devs could really get behind the BU movement.

 

[solex]

Complete backward compatibility in all aspects and use cases that *anyone anywhere ever* falsely advertized as permanently usable-without-ever-upgrading is quite a restrictive principle.

At some point it's got to be acceptable to expect some level of wallet devs keeping up with developments and merchants keeping their apps updated if they want to use edge cases like 0-conf.

Unfortunately it is not this simple. A merchant receiving an opt-in RBF tx receives a reduced quality user experience. 0-conf is also not really an edge-case, it is a reasonably significant use-case.

Has everyone made a zero-cont purchase yet? There is one bar that I can use which does, and the bartender will pick up an iPad and watch for the incoming tx and listen for the bleep noise. As soon as this happens the iPad is put down and the drink poured. The problem now is that there needs to be an extra signal that something is wrong after the bleep.

When merchants accept coinage there has been the age-old problem of whether the customer has passed a fake coin or a foreign one. Merchants have always been aware of this. With Bitcoin that problem goes away. What I am seeing is that opt-in RBF re-introduces the age-old "fake-coin" problem which Bitcoin has recently solved.

Now, its easy to say that the 0-conf was never safe and that the bartender needs to keep an eye on the iPad for a double-spend alert, however these seem to be rare enough that this isn't happening. Opt-in RBF makes it so easy to double-spend that it will force all merchants to be suspicous of a 0-conf tx. That is too much of a hassle for many.

With the potential of subchains for making the existing 0-conf usage even safer it makes a holistic assessment of opt-in RBF an even more important exercise.

 

[TrevinHofmann]

The problem now is that there needs to be an extra signal that something is wrong after the bleep.

RBF does not change this. Even if a 0-conf transaction is usually safe, double spends can and do happen. Systems should already support this possibility.

Opt-in RBF makes it so easy to double-spend that it will force all merchants to be suspicous of a 0-conf tx. That is too much of a hassle for many.

Identification and reputation fixes this in most cases. You don't want to be the person caught on camera stealing a drink for a few dollars.

In cases where the customer cannot be identified (anonymous online marketplaces, casinos, and exchanges), 0-conf is already unsafe. The cost of attempting a 0-conf double spend is practically zero.

 

[Zangelbert Bingledack]

A merchant receiving an opt-in RBF tx receives a reduced quality user experience.

So merchants just wouldn't accept opt-in RBF tx's, no?

I imagine in the wallet software the merchant would have tapped an option at setup specifying their use case "□ I want to accept transactions instantly." In that case, the wallet would say something like, "INVALID TRANSACTION RECEIVED. ASK USER TO SEND NORMAL TRANSACTION."

Similarly, on the user side, the opt-in RBF would have warnings telling the user that the transaction will likely not be accepted at brick-and-mortar shops. The user-friendliness aspects are details for the wallet apps to sort out, but it doesn't seem particularly hard.

 

[theZerg]

Without studying this enough, I'd imagine that a miner could determine if a transaction is important to clear out a LN channel. So miners could only allow RBF for these. No explicit RBF needed... or default mining alg could simply prioritize these txns as a service. This whole concept is interesting because it means if LN is not in miners interest they could refuse to confirm the txn.

Does anyone have time to research these angles and confirm or disprove them?

 

[solex]

@TrevinHofmann
I am thinking that there must be at least 100 different wallet applications and how they will each handle opt-in RBF will be on a grey-scale of competency.

I imagine in the wallet software the merchant would have tapped an option at setup specifying their use case "□ I want to accept transactions instantly." In that case, the wallet would say something like, "INVALID TRANSACTION RECEIVED. ASK USER TO SEND NORMAL TRANSACTION."

It's still not that simple because the user has made a valid transaction. It is just that the merchant can't trust it yet. I would not be surprised if most opt-in RBFs in a 0-conf situation are accidental not deliberate.

Similarly, on the user side, the opt-in RBF would have warnings telling the user that the transaction will likely not be accepted at brick-and-mortar shops. The user-friendliness aspects are details for the wallet apps to sort out, but it doesn't seem particularly hard.

Right. So, let's imagine that a user normally has opt-in RBF enabled because he buys on-line, and surprise surprise, blocks are normally full so this is occasionally useful. He goes to a bar and at the moment of paying overlooks the 0-conf situation.

Then the merchant has to go to his crib-sheet for handling RBF tx:

a) do I know the customer? Yes, then accept payment otherwise b) etc.

b) ask customer to wait in corner and come back when a block is found (might be anywhere like 5 or 50 minutes, but hey)

c) ask customer for a fiat banknote as a bond, to return when customer finishes drink (assuming a block is found by then).

d) ask customer to RBF himself with a higher fee to another address he owns and then set opt-out and make payment (but note that a miner may hash a block including original tx and now customer needs a BTC refund).

aaaargh!

 

[TrevinHofmann]

do I know the customer? Yes, then accept payment otherwise

You don't need to personally know the customer; any identification will do. Keep in mind, the equivalent of a Bitcoin block confirmation can take months for a credit card transaction.

 

[Zangelbert Bingledack]

@solex

It seems to me these are all just user-interface issues. If a guy is buying online usually, he's probably going to have to click through some warning about brick and mortar shops every time. I'm not sure how he's not gonna know. Maybe wallet software is pretty user-unfriendly today, but I anything that's just a matter of informing the user seems pretty doable, even if some wallets will get it wrong.

EDIT: I see, you mean if he just accidentally sends it. I dunno, seems like people have to be pretty careful with a lot of things. What if they just accidentally send a bank wire to the wrong account, etc.
[doublepost=1451795537][/doublepost]Oh, I think I have a better answer: PoS they'll be using something like NFC or whatever, so the wallet would not let the user pay with opt-in RBF, unless they jumped through some big warnings. I guess QR code would be ambiguous, but then again perhaps the QR code could be made to include "RBF-OK" markers in the code somehow for online retailers, so that PoS where they have legacy QR codes would trip a big warning in the wallet.

 

[solex]

@Zangelbert Bingledack
Yes. Good point. QR code info should tell the sender's wallet whether opt-in RBF is acceptable or not. This can all work in theory, but will all the major wallets cover these scenarios before Core does their release?

 

[Zangelbert Bingledack]

@solex

Yeah it's definitely an ill-considered (or well-considered blatantly Blockstream-aiding) move to rush it in like that. It's the kind of thing that should have had 6-12 advance notice, but instead was kept on the more obscure Core comm channels.

 

[Inca]

Only 2100 nodes actually run the latest Core client. Even if all of them upgrade then most of the network doesn't support opt-in RBF.

Opt-in RBF is only an issue for 0-conf transactions until the first confirmation is seen. Clearly there needs to be a strategy from the merchant over how to accept or decline these troublesome transactions.

@Zanglebert Bingledack: I am not sure

"INVALID TRANSACTION RECEIVED. ASK USER TO SEND NORMAL TRANSACTION."

will be effective because the sender has already sent the funds, requiring the wallet to RBF the funds back to the wallet and resend again without the flag or simply for the merchant to enforce a wait on releasing the product (which is not feasible in bricks and mortar situations with a variable wait for block confirmation)! For a new user to bitcoin being faced in a situation where a transaction fails but the funds have gone from their wallet this could be very negative outcome.

i like this solution @solex is elegant:

QR code info should tell the sender's wallet whether opt-in RBF is acceptable or not.

But again this requires a change to be implemented by all wallet software so the funds are not sent anyway. What an unnecessary addition of complexity to a working system.

It is almost as if the Core team are saying - 'no more bricks and mortar or 0-conf transactions, thanks'.

 

[TrevinHofmann]

It is almost as if the Core team are saying - 'no more bricks and mortar or 0-conf transactions, thanks'.

This is hyperbole. Brick and mortar purchases rarely need instant confirmation. Adding support for RBF to wallets is not a major task for developers.

 

[Inca]

This is hyperbole. Brick and mortar purchases rarely need instant confirmation. Adding support for RBF to wallets is not a major task for developers.

I would respectfully disagree @TrevinHofmann. With confirmation times varying wildly up to multiple hours in some cases, bricks and mortar purchases almost never don't need instant confirmation as the overwhelming majority pass through payment processors who make this risk assessment themselves.

And the point of this last few posts by various people is that the issue is not necessarily with just the wallet implementation but with the merchant. There are a number of new issues this 'feature' creates on both sides that are unnecessary IMO.

What is wrong with 1) merchant happy to accept 0-conf and take the risk at their choosing and 2) merchant unhappy to accept 0-conf and therefore waiting for 1 or more confirmations?

Anyway I don't want to derail the thread. The original BUIP is for users to decide democratically how BU as a client should deal with this interesting subject. I am curious to know your views on that.