BUIP004 (passed A1): RBF/double spending support

[TrevinHofmann]

I would respectfully disagree@TrevinHofmann.

No problem. That's the best kind of disagreement.

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 issue does it raise for merchants? Double spends are already a possibility that merchants or their payment processors should account for. For the end user experience, things like RBF can be abstracted away from view.

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.

I think it should be as configurable as possible for the user, with the popular configuration as the default.

 

[Roy Badami]

Anyone know what the maximum post size is here? My draft post on the subject has started to get somewhat longer than I had expected (and it's not finished yet).

 

[solex]

@Roy Badami
10,000 characters.

 

[Roy Badami]

Thanks. It probably makes sense for me to post it elsewhere when it's done and link to it.

EDIT: 25,000 characters and counting LOL

 

[Inca]

Looking forward to this magnum opus!

 

[theZerg]

Merchants weighing in:
https://www.reddit.com/r/btc/comments/3ze0sz/why_bitcoin_0_confirmation_transactions_are_safe/

 

[Inca]

We are on the right track with this BUIP I think. It could be a major attractor for BU.

 

[bitcartel]

Anybody want to present a positive case for RBF?

Unless there is a compelling business case and genuine demand from users for RBF, I think A1 or A2 are reasonable choices for this BUIP.

BU should provide the user with a config file / command-line switch to decide whether or not they want to relay RBF transactions - with the default being set to OFF.

 

[Zangelbert Bingledack]

Only positive case is if users choose a low blocksize cap and there's a need to jump queue because of tx backlog.

 

[freetrader]

Good point made in that thread Opt-in RBF effectively only being harmless for the sender:

[doublepost=1451956878][/doublepost]

Only positive case is if users choose a low blocksize cap and there's a need to jump queue because of tx backlog.

Wait a minute, certain payment channel solutions might also need it because of a need to adjust settlement transactions...

You know what, scratch that, because if people run BU, such payment channels would likely not be profitable soon enough to worry about the need for RBF.

 

[Zangelbert Bingledack]

Interestingly, Satoshi's famous quote, "If you don't believe me or don't get it, I don't have time to convince you, sorry," was actually in regard to how 0-conf would work, not about Bitcoin in general.

http://web.archive.org/web/20150905055316/https://bitcointalk.org/index.php?topic=532.msg6306#msg6306

 

[Aquent]

Double spending a transaction isn't really that easy. You always have to deal with probability and under the current rules, unless I am mistaken, probability is never 100% or anywhere near that. Any double spend, and even 1 confirmed spends that happen is, from what I'm aware, because of Eligus Luke-Jr's pool, because, I think, they accept non standard transactions, but with some minimal measures, you can, as satoshi said back then:

"verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less.
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819"

Peter Todd calls that DDosing though as he'd rather bitcoin was inconvenient to use so that it can be kept small so that, according to him, it is more decentralised, so that, according to him, it can withstand USG, but with miners now in mining farms that bridge has long gone.

 

[TrevinHofmann]

You always have to deal with probability and under the current rules, unless I am mistaken, probability is never 100% or anywhere near that.

Success does not need to be 100%. The profitability for double spend attempts is something like this:

E = p*P - c*(1-P)

... for expected value E, profit of success p, cost of failure c, and probability of success P.

The following is required for a positive E:

p*P > c*(1-P)

Assuming a positive profit of success and cost of failure, we can solve for the required probability of success:

P > c / (c + p)

Here's a spreadsheet of the minimum double spend success rate at which the attack is profitable, with the values for c increasing to the right and values for p increasing downward:

Note: These are rough calculations. There are other variables to consider.

 

[Aquent]

I am not really able to verify your math, but what would be more interesting to analyse is the probability that your second (double spend) transaction is seen first and thus mined.

For a realistic analysis of that probability you'll probably want to analyse Eligus's pool behaviour and take it's unique parameters into account.

You'll probably then want to consider the above in light of the suggestions made by satoshi to minimise any 0conf double spend in the thread I linked above and see how they change.

The end results should be sufficiently interesting to contribute some new knowledge to bitcoin's ecosystem.

My opinion is that the relative security of 0conf transactions can prob stand on maths alone (although of course not 100% but better than credit card chargebacks), without even taking into account human incentives, but some academic full analysis, including analysis of methods that can be taken to make 0confs even more secure, would be quite interesting.

 

[solex]

I am a massive fan of empirical evidence. When a restaurateur reports having accepted >1000 zero-conf tx without a problem then this outweighs any amount of hot-air and hand-waving about how "zero-conf was always broken" (c) [Todd / Friendenbach]

 

[TrevinHofmann]

My opinion is that the relative security of 0conf transactions can prob stand on maths alone

I don't really want to work out the math right now, but 0 confirmation transactions are usually safe because of repercussions, not because the network is honest. You wouldn't double spend at a restaurant for the same reason you wouldn't charge back your credit card transaction. It is not worth the damage to your reputation.

In places where your identity is unknown and there are no repercussions, the brief analysis I just posted shows the profitability of the attack. If a casino has a 1% house edge and uses 0 confirmation transactions, they're almost certainly going to be victims of 0 confirmation double spends. The house edge would give a p value of 0.495 and a c value of only 0.005 for a bet with a 2x potential payout. At any rate of success greater than 1%, a double spend attempt becomes profitable.

Regardless of the support for 0 confirmation by most miners, any single miner with at least 1% of the hash power could reliably succeed with at least 1% of their double spend attempt.

I am a massive fan of empirical evidence. When a restaurateur reports having accepted >1000 zero-conf tx without a problem then this outweighs any amount of hot-air and hand-waving about how "zero-conf was always broken"

In a restaurant, there are (often) penalties for a double spend. This is why you wouldn't see many double spend attempts. If you'd like to use the equations I wrote above, you would actually have a negative p value. Even if you succeed in skipping out on a $10 bill for lunch, you would also succeed in doing more than $10 worth of damage to your reputation and likely facing criminal charges.

In those situations, it isn't the network's support for 0 confirmation transactions that stops you. It is the repercussions. Those repercussions would be the same with or without RBF support.

This is why 0 confirmation transactions are not safe for large or anonymous payments for irreversible goods/services. In these cases, the p is much larger than the c.

 

[freetrader]

I am a massive fan of empirical evidence. When a restaurateur reports having accepted >1000 zero-conf tx without a problem then this outweighs any amount of hot-air and hand-waving about how "zero-conf was always broken" (c) [Todd / Friendenbach]

Trust, but verify

 

[seweso]

I'm definitely against trying to block RBF. The use case for RBF transactions and zero-conf do not overlap (and they can't obviously).

For RBF it is trying to pay the lowest fee and not caring about fast confirmation (expecting zero-conf to work would be weird). For zero-conf it is paying a reasonable fee to get fast confirmation (expecting rbf transactions to work would be weird)

There only need to be a few miners who support RBF for it to be effective already. It is not really something you can fight.

What is important is making sure wallets do not create RBF transactions by default. That would be a huge mistake. But that's just something which needs to be made clear to everyone. I expect wallet developers to understand the value of zero-conf.

 

[Inca]

@seweso: RBF does the exact opposite of allowing you to pay the lowest fee - it allows you to bid the fee higher and higher actually.

Sure a miner may choose to deliberately support RBF, but the non-mining nodes on the network have to relay such transactions to said miners. If they do not then it makes the feature effectively dead except for very motivated thieves.

Plus, mining pools acting against the interests of the network (unless they are vertically integrated solutions) will rapidly find their hash power moving elsewhere.

 

[seweso]

RBF does the exact opposite of allowing you to pay the lowest fee - it allows you to bid the fee higher and higher actually.

Maybe its counter intuitive. But because you can bid more later you can initially bid less.

And I believe some miners already ran/run with RBF policies with the help from Peter Todd.

Look, I'm pro zero-conf, and I hate what Peter Todd has turned the community into (he started the whole 1mb is good movement). But still doesn't make Opt-in RBF a bad thing by itself.

Although if blocking RBF helps to raise awareness about weird consensus forming by Core. Then maybe it is worth it to fight it.