Full RBF

[o_e_l_e_o]

Bitrefill, as a successful business, ought to switch to lightning.

They already support Lightning. But as per their CEO's post here, Lightning transactions only make up around 15% of their business, while zero confirmation transactions make up 60%. This is a huge disparity. It's not enough to simply say "Use Lightning", when probably the majority of those 60% either have no experience with Lightning or aren't even holding their own coins at all.

More nodes that have Full RBF means more chances for everyone to establish connection with nodes that have Full RBF. Therefore, more chances for an attacker to take a user's transaction and hand it over to the miner.

Yes, but that doesn't matter if the miner in question is running their own node(s) which have full RBF disabled. Their nodes will reject such a transaction, and so the miner won't include it.

[1715299628]

1715299628

[1715299628]

1715299628

[1715299628]

1715299628

[1715299628]

1715299628

[1715299628]

1715299628

[1715299628]

1715299628

[BlackHatCoiner]

They already support Lightning.

Right. I'm buying gift cards frequently from that place.  

Lightning transactions only make up around 15% of their business, while zero confirmation transactions make up 60%

Ouch! People, justifiably, don't use lightning often yet. Either because it's responsibly tough to run your own lightning node, or because just using bitcoin without custodians is already too confident for the average Joe to make him get involved further.

They need to understand they can't have that unconfirmed option forever though. To increase that 15% they could provide greater rewards for purchases with lightning.


Edit:

Yes, but that doesn't matter if the miner in question is running their own node(s) which have full RBF disabled. Their nodes will reject such a transaction, and so the miner won't include it.

It's reasonable to assume that such attacker is a miner.

[DaveF]

They need to understand they can't have that unconfirmed option forever though. To increase that 15% they could provide greater rewards for purchases with lightning.

If my old man memory is correct they used to give you a bit more. Not a lot more but a bit. Could have been fold, really not sure but I do remember getting a better discount someplace when using lightning for giftcards.

What they COULD do is keep smaller lightning channels open to them. I have opened a few and they auto close them after a while even while being balanced with a decent amount. Don't know why, and finally gave up caring sometime over the summer. Just stopped trying.

Back OT, did spend some time reading since my last post. I still think we should wait, but I do see the other sides view a bit more.
<shrug>
Beating a dead horse, it's going to happen.....

-Dave

[BrotherCreamy]

The merchants who are crying about full RBF because it stops them from accepting zero-confs are idiots.

IMO having an option in your node software which gives the node operator the choice to obey/ignore the RBF flag should be uncontroversial.

It has nothing to do with consensus. It should be as controversial as giving node operators the ability to change the appearance of the Core GUI.

[o_e_l_e_o]

They need to understand they can't have that unconfirmed option forever though.

Absolutely, but it would be a lot easier to make that argument if the numbers were flipped, and 60% of their business was via Lightning and only 15% via zero confirmation transactions. And we'll only get there with more time.

It should be as controversial as giving node operators the ability to change the appearance of the Core GUI.

This is obviously not the case. If every node on the network swaps to a dark themed GUI, nothing changes for anyone else. If every node on the network swaps from opt-in to full RBF, then a lot of things change for a lot of businesses and entities.

[BrotherCreamy]

This is obviously not the case. If every node on the network swaps to a dark themed GUI, nothing changes for anyone else. If every node on the network swaps from opt-in to full RBF, then a lot of things change for a lot of businesses and entities.

But that's my point. It's a nothing feature. It's not part of the protocol so it's meaningless. It should be a checkbox in the UI.

I really don't understand how there could be so much debate over a feature that ISN'T EVEN PART OF BITCOIN.

If anything this debate just demonstrates that Bitcoin development is a monoculture.

Someone should release a "jailbroken" version of Bitcoin Core that allows you to have your node behave in any way you want.

[o_e_l_e_o]

I really don't understand how there could be so much debate over a feature that ISN'T EVEN PART OF BITCOIN.

Then you should have a read of the mailing list post from one of the developers of Muun wallet and the CEO of Bitrefill. Here they are:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020980.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021056.html

Just because you see it as a "nothing feature", does not mean it won't have significant implications on how some businesses operate.

Someone should release a "jailbroken" version of Bitcoin Core that allows you to have your node behave in any way you want.

I mean, anyone can change any setting they like in their node and have it run any way they want already. In terms of full RBF, this has always been possible, as I said above, simply by changing some code yourself or running a client such a Knots which provides it as an option.


24.0 has been released. Will be an interesting few months to see how the mempool behaves.

[NotATether]

Someone should release a "jailbroken" version of Bitcoin Core that allows you to have your node behave in any way you want.

All you have to do to accomplish that is expose all of the internal constants and behaviors that are hardcoded into Bitcoin Core to the ArgsManager (i.e. the command line and bitcoin.conf). There's really not much to it.


Anyway, what the hay. I downloaded and ran 24.0 and set mempoolfullrbf=1 in my bitcoin.conf. This will solve woes with wallets which refuse to support the RBF feature.

[NeuroticFish]

24.0 has been released. Will be an interesting few months to see how the mempool behaves.

Since the new release is not visible yet neither on bitcoincore.org nor bitcoin.org, this will still take a while...

( And I see everybody is eager to tell this to achow101 )

[o_e_l_e_o]

Anyway, what the hay. I downloaded and ran 24.0 and set mempoolfullrbf=1 in my bitcoin.conf. This will solve woes with wallets which refuse to support the RBF feature.

I haven't upgraded yet, bet when I do I'll likely enable it as well. I don't really want my node to holding on to transactions which other nodes have already replaced. Although it could also go the other way, in which my node accepts a replacement transaction, but the original ends up getting mined. Could be a bit of a mess for a while.

( And I see everybody is eager to tell this to achow101 )

Lol. I'm pretty sure he's aware of 24.0 being released, considering he is one of the people who signs the checksum file with each release.

[DaveF]

Anyway, what the hay. I downloaded and ran 24.0 and set mempoolfullrbf=1 in my bitcoin.conf. This will solve woes with wallets which refuse to support the RBF feature.

I haven't upgraded yet, bet when I do I'll likely enable it as well. I don't really want my node to holding on to transactions which other nodes have already replaced. Although it could also go the other way, in which my node accepts a replacement transaction, but the original ends up getting mined. Could be a bit of a mess for a while.

Kind of funny I was actually going the other way and thinking that I am not going to enable it for a while on any of my nodes that have funds.

Since, at the moment the only nodes I am running that have funds are all tied to lightning channels I figure it's safer at the moment to wait.
The ones that don't have funds are all up and down and not as reliable for others to connect to so it probably does not matter as much.

-Dave

[nz6lngmv]

Hi.
In my town we have a few different companies with bitcoin ATMs. In my town we have two. They differ in the way that one needs 0 confirmation and i can withdraw fiat, the second needs 1 conf.
We all now that 1 conf can take every where from 1minute - 50 minutes. And yes. There was a time when i needed to wait 50 minutes and check mempool space when the block was mined. It was not at least pleasant.
You can see which of the two ATMs is more popular with me. The 0 conf ATM gives me fiat like experience.
The 0 conf ATM is also the more widely spread one in my country. The company that runs it obviously knows what risk 0 conf means for them and it obviosuly knows what benefit and userexperience it gives their users.

If this update stops that 0 conf UX. Then i think we all must be aware that it is starting to produce a split. If i read the blocksize wars correctly, then possibly a fork.
Please be aware that this change puts significantly implications in the social consensus layer.
I will most certainly not update any of my nodes with this update.

And if this thing also harm creating of just in time LN channels.... than i do not know who exactly is for bitcoin adoption.

Maybe the current update is good. But in the current circuimstances of adoption bitcoin it makes more harm than good.

Developers please reconsider what this update is achieving in the social layer and if we realy need it right now.
I strongly advice to retract it.

[BlackHatCoiner]

If this update stops that 0 conf UX. Then i think we all must be aware that it is starting to produce a split. If i read the blocksize wars correctly, then possibly a fork.

As said by ETFbitcoin, this has nothing to do with blocksize wars. RBF is a local setting. One could, can and will always be able to propagate double-spends of RBF-disabled transactions. This change (which isn't a significant change anyway) won't bring hard forks or soft forks. It won't even result in forking in a reorg way.

Maybe the current update is good. But in the current circuimstances of adoption bitcoin it makes more harm than good.

Perhaps, but it's inevitable to have it someday, and maybe this day has come. Some find it essential, while some don't. The network might be a complete mess for a while, but in the end, the former will outweigh the latter, because that's the natural state of the network.

To put it this way: there's no end to the users' ability to alter their local settings. This feeling that 0-conf is safe, introduces trust, because you're at the mercy of the rest.

[o_e_l_e_o]

Developers please reconsider what this update is achieving in the social layer and if we realy need it right now.

You can read the rationale behind it here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

I strongly advice to retract it.

This has been discussed to the death across multiple pull requests, and has now already been released. Only if some earth shattering bug or vulnerability was discovered (which is highly unlikely) would anything change for v24.1.

Bitrefill are still accepting zero confirmation payments at the moment, and I don't use Muun wallet but don't see any announcements on their Twitter or website. I assume they will both be monitoring how quickly this is adopted and then implement changes as necessary.

[nz6lngmv]

please explain me, how  will i get fiat from an bitcoin ATM in an instant with this new update?

[o_e_l_e_o]

please explain me, how  will i get fiat from an bitcoin ATM in an instant with this new update?

I don't know how your local ATM company is going to handle it. The fact is that zero confirmation transactions were never completely safe, and all businesses which rely on them were going to have to adapt to a better model at some point. That point is now (or at least, within the next few months).

The most obvious answer is Lightning. For an ATM this seems like the easiest option. Display an invoice, you scan the invoice, it spits out cash, or you create an invoice, show it to the ATM's camera, and it sends you the bitcoin. Other options are to continue to accept zero confirmation transactions in the short term but make their exchange rate for such transactions worse to cover for the increased risk, or to require a minimum of one confirmation for everything. You'll have to wait and see which route they choose.

[o_e_l_e_o]

Alternatively they could spend the unconfirmed output immediately so low-effort attacker can't simply perform RBF. Although it's at cost of higher fee or higher minimum deposited Bitcoin.

That doesn't solve the problem though. The ATM owner would still need to wait for one confirmation on their CPFP transaction so as to prevent the attacker just upping the fee even more and double spending the parent back to themselves. It doesn't matter if you are waiting for one confirmation on the attacker's transaction or on your own CPFP transaction - you are still waiting for one confirmation.

[NotATether]

please explain me, how  will i get fiat from an bitcoin ATM in an instant with this new update?

What is the name of your ATM operator if you don't mind sharing it? I might send them an email about it.

[nz6lngmv]

Please look at the 0conf issue from the side of a normal fiat user. Its tempting to look at it from the developers side. Its very hard to be against 0conf if you understand that you will need to wait at the ATM. Look at this issue from a perspective of an individual, who has only a signing device and no node. Or he has a node, but not a LN node. its hard to manage a LN node.

I don't know how your local ATM company is going to handle it. The fact is that zero confirmation transactions were never completely safe, and all businesses which rely on them were going to have to adapt to a better model at some point. That point is now (or at least, within the next few months).

Why? Why would this point be now?
You do not know how companies are gonna adress the changes and at the same time, that is perfectly fine?
everyone knows 0conf tx is riski. and after the update it will still be. the only change is that 0 conf are not possible anymore.

The most obvious answer is Lightning. For an ATM this seems like the easiest option. Display an invoice, you scan the invoice, it spits out cash, or you create an invoice, show it to the ATM's camera, and it sends you the bitcoin. Other options are to continue to accept zero confirmation transactions in the short term but make their exchange rate for such transactions worse to cover for the increased risk, or to require a minimum of one confirmation for everything. You'll have to wait and see which route they choose.

The problem with LN has been presented before. It is not used widely enough.
If i wanna use it selfcustodyed, then i need to learn channel balancing and i do not know what all things. The other way i could do is to trust someone to have a LN node and he does all his work (an LSP like breez). But that is not self custody. LN has come a long way in the terms of usability. The two bugs that happened recently shut down my node...
Right now LN is not in a state to push it on everyone. LN is still "beta".
Onchain is the lowest layer and it has functioned realy well and stable. And still is. This change is taking a "hack" away, where companies used it as a good UX way. Developers are now taking that away, for no apparent reason. The bussines already know it was risky.

[o_e_l_e_o]

Its very hard to be against 0conf if you understand that you will need to wait at the ATM.

I have previously frequently used zero confirmation transactions when transacting in person. This change is not ideal for me either, but I understand why it needs to happen. Moving forward I suspect I will continue to use them at a few merchants with whom I have built sufficient trust, and at other merchants I'll be looking at using Lightning instead.

Why? Why would this point be now?

Because 24.0 with the mempoolfullrbf setting has already been released and it isn't going to be reversed. Like it or not, I'm afraid that point is now.

You do not know how companies are gonna adress the changes and at the same time, that is perfectly fine?

I never said that. In fact, I argued to delay this until 25.0 to allow such companies to address it. But arguing about it now, when it has already been released, is pointless.

everyone knows 0conf tx is riski. and after the update it will still be. the only change is that 0 conf are not possible anymore.

Still possible, just more risky than before.

Developers are now taking that away, for no apparent reason.

There are many very legitimate reasons, with one of them being that it is necessary for certain Lightning developments. This isn't just being introduced for the fun of it. I would suggest you read the links I provided previously.