What is RBF and why did the community reject it?

[xinayder]

Since asking on the subreddits leads to nowhere, I'm asking here instead.

What is this new RBF proposal that they implemented on 0.12, what does it do? And why did the community reject it?

 

[yrral86]

RBF allows you to replace an unconfirmed transaction with a new transaction with a higher fee. The problem is if you pay someone and they accept 0-conf you can walk away and then redirect the payment back to yourself. While the is possible without RBF it is much harder to pull off. Many businesses find the risk of 0-conf fraud to be small enough to accept, but RBF would make it trivial to pull off. This would shift the risk higher and a lot of businesses would no longer find it an acceptable risk.

 

[Georg Engelmann]

Adding RBF to a wallet is like adding a button to your credit card to reverse payments – of course you could always call VISA, Mastercard, American Express to reverse payments, but why should it be presented as an option?

• You are planning to conduct business with people who are going to defraud you
• You are planning to use RBF to defraud people
• You are expecting Bitcoin to be so unreliable that nobody could predict a reasonable fee when you initiate the payment

Even if it only allowed you to "bump the fee" it would be inconvenient, because as a user you want to know the exact amount you are going to pay before the payment is initiated.

 

[rebuilder]

Yrral86's explanation is for the original RBF proposal. What was implemented is opt-in RBF. Most importantly, the sender can choose whether or not to enable this, and the recipient can tell whether or not a transaction they're receiving could be replaced by one with a higher fee.

Now, I'm not convinced the hassle this introduces is worth the benefits, but I'm also not really seeing how it's all that horrible.

 

[freetrader]

@rebuilder, I always ask people who think opt-in RBF is not horrible to share what their thoughts are on this example, and whether they think it would play out much differently:

 

[rebuilder]

PattayaPete: I saw that before somewhere, and I agree it wouldn't be a good user experience. Falls under the hassles I mentioned.

That said, I find it difficult to believe wallet software wouldn't change to warn you seriously about the consequences of using RBF if your scenario happened frequently. So hassle, yes, unnecessary maybe, end of the world, hardly.

 

[solex]

Some truly excellent background reading about fee updating with focus on RBF.

https://gist.github.com/roybadami/7bd2ea56a06984fedace

This is a rats-nest of a subject and just because RBF is "opt-in" does not make it fine and dandy.

 

[jl777]

the problem is not RBF, the problem is that blocks are full which makes it impossible to predict the fee needed to be confirmed. That makes zeroconf broken.

RBF behavior is already possible, it defines previously undefined behavior.

mixing zeroconf with a non-permanent sequenceid is horrible design. Trying to use RBF to work around the fact that blocks are full is not going to work.

Full blocks break zeroconf. So if zeroconf is broken, then adding anything, it is still broken. Might as well say multisig breaks zeroconf since you cant be sure the tx will be confirmed when the blocks are full. p2sh breaks zeroconf since you cant be sure the tx will be confired when the blocks are full. everything breaks zeroconf when the blocks are full, since it is already broken.

how exactly can one be sure a tx will confirmed before it is confirmed, if there are more tx in the mempool than can be confirmed?

RBF has been politicized (illogical arguments used to justify either position), RBF does change sequenceid field to be the RBF field and that is bad design and an overreach, so I dont like it for that reason. but defining how a mempool tx is treated is not any problem. If the rerouting of funds is such an issue, change it so only the change address can have its output reduced and all others outputs must be the same or more.

zeroconf is the lowest security method for tx. RBF are non-permanent sequenceid's. Mixing the two is like combining drinking and driving. The fact that we are thinking about doing it, is because the blocks are full and zeroconf is already broken
[doublepost=1457991206][/doublepost]

Some truly excellent background reading about fee updating with focus on RBF.

https://gist.github.com/roybadami/7bd2ea56a06984fedace

This is a rats-nest of a subject and just because RBF is "opt-in" does not make it fine and dandy.

good summary.

FSS-RBF: First seen safe RBF
and define the first output as the change address. Then there is no danger of double spend and it wont be very hard to figure out if it is valid or not.

The big technical problem is how to deal with "first seen". First seen, by whom? which node? So we can end up with half the network having seen txA first and the other half txB first.

However, this is ok, as the usual zeroconf technique of checking the other node's mempools could detect that case.

 

[freetrader]

Thanks @solex for remining about @Roy Badami 's excellent post.

zeroconf is the lowest security method for tx. RBF are non-permanent sequenceid's. Mixing the two is like combining drinking and driving.

Excellent description, well done - I have to remember that one.