Topic: Full RBF - page 5. (Read 3043 times)

Actually, Breez is self-custody. Your keys are on your device and on your device only. Breez integrates on-chain swaps and manages your channels automatically, but it's not their server that does it (which would require trust), but your application, locally on your phone.

Which bugs exactly? You can just start the node back up, right.

Core Lightning is meant to be as lightweight and basic as possible, and allows you to install whatever 'extras' you want on it manually, through its plugin interface.
There is an autopilot plugin.

It should also be very easy to set up using Umbrel for instance.

The lowest barrier to entry that is non-custodial, is Breez. No setup, nothing, all automatic, but still gives you access to LND's commands in case something goes very wrong.

It's already easy to setup. Just go and buy a RPi or a cheap laptop, and install one of the Bitcoin node OSes there are, such as Umbrel, Raspibolt, Raspiblitz, myNode etc. The problem doesn't lie there. It lies on the cost of maintainance. From a customer perspective, you need to have a device running all day and night, verifying transactions. There's no such thing as SPV, unless you lose custody. And I'm afraid that the vast majority of Bitcoin users either lose custody or do own their keys, but use SPV.

It doesn't open channels by default, but that's a trivial thing to do. Just open channels with one or two large node operators. Channel balancing does neither come pre-installed.

At this point, we should start an effort to make LN nodes easier to use.

You should be able to run them and then it goes on autopilot like Bitcoind. I have ran c-lightning before: I am not quite sure whether it does channel balancing or even whether it automatically opens channels by default.

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.

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.

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.

Still possible, just more risky than before.

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.

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.


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 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.

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

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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 )

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.

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.

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.

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.

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.

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.

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.