Full RBF

[NotATether]

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.

[BlackHatCoiner]

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

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.

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.

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.

[n0nce]

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.

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.

LN has come a long way in the terms of usability. The two bugs that happened recently shut down my node...

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

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.

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.

[nz6lngmv]

This thing is not going on my node.

LN is not easy to use. Maybe umbrel is easy to install. At the same time this things break. Many times i could solve it with my linux skills. However there are occasions where my node was out for month+. It uses docker which is new and thus needs new skills to acquire and maintain.
The whole balancing act is hard. Maybe it is easy for a developer. It is not like setting it up and forgeting it.

and saying 0.24 is out and there is nothing WE can do about it is just... well if i push someone over the cliff, then it is gameover. Taking down a software update is nowhere near pushing someone over the cliff, the thing is not live on the public download...

[o_e_l_e_o]

This thing is not going on my node.

Which is absolutely your right. If you don't like it, then don't enable it. But similarly, you don't get to tell everyone else not to enable it. And I'd point out again that the default setting here is false i.e. disabled.

Taking down a software update is nowhere near pushing someone over the cliff, the thing is not live on the public download...

It is tagged on GitHub as the latest release, and it is available on bitcoincore.org. There are already 230 nodes running it according to blockchair. And even if you succeeded in getting 24.0 pulled (which would not happen), then anyone who wants this option can still download the necessary code from GitHub.

Still, if you want to argue against it, then here is the latest pull request to remove the option: https://github.com/bitcoin/bitcoin/pull/26525. I would strongly suggest you read all the comments in this request plus the 4 other pull requests I linked to previously, because you are simply rehashing arguments which have already been had.

[BlackHatCoiner]

But average people wouldn't bother run a node even if it's easy to setup.

Exactly. If you want to use lightning in a simple manner, you either hand over custody, or you pay for someone else to watch for cheating attempts, both of which aren't meant to be taken seriously, justifiably. Handing over custody on cryptocurrencies is just ironic. Paying for watchtowers is also very unattractive, and it doesn't eliminate trust.

and saying 0.24 is out and there is nothing WE can do about it is just...

You can let it to default. You can't do much, and you've got to acknowledge that full rbf is the natural state of the network, because ethics are secondary in mining. You can't expect global adoption to come with 0-conf.

[n0nce]

It uses docker which is new and thus needs new skills to acquire and maintain.

Docker is almost 10 years old. Umbrel is made mostly with non-tinkerers in mind who conveniently install 'applications' which automatically run in their own containers. There is not much to maintain.

The whole balancing act is hard. Maybe it is easy for a developer. It is not like setting it up and forgeting it.

Personally, I mostly 'forget' about my Lightning node; sure, I don't route a lot of traffic, but as my channels are (and remain) balanced due to low usage, whenever I need to send or receive a payment, it works really well.
You don't need to have the 'ultimate high throughput routing node' on the network to use Lightning efficiently for personal usage. I feel like this is often overlooked.

Just like you probably don't serve the blockchain to 100,000 peers simultaneously over IPv4, IPv6 and Tor from your home node.

[NotATether]

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.

But average people wouldn't bother run a node even if it's easy to setup. For them, it's more convenient to run lightweight LN wallet such as Electrum, BlueWallet or Phoenix wallet.

Average people are not the ones who run nodes. Advanced users do.

LN acrobatics need to be made easier to manage (or put on autopilot) for power users. Because I myself am not running a Lightning node, despite running a Bitcoin node. That is despite me falling in the category of technical people (which I'm sure ns6lngmv is as well).

I used to run a Lightning node when I had a BTCPayServer, but getting the node in a working state to accept connections became too much of a trial-and-error. Maybe because C-Lightning is tethered to Bitcoind. I don't know. All I know is that LN is not intended to be a Bitcoin Core-specific thing.

Right now, I can literally set up a config file, run bitcoind, and then forget about it for a month or so. The fact that I'm hearing that LN nodes require additional maintenance worries me, that this may be the reason that it's not getting close to as much adoption as Bitcoin Core.

A c-Lightning or LND (or other) developer needs to come and make a statement here about LN nodes.

[n0nce]

A c-Lightning or LND (or other) developer needs to come and make a statement here about LN nodes.

Regarding what exactly should that statement be? What exactly is unclear? Related to RBF or something else?

[NotATether]

A c-Lightning or LND (or other) developer needs to come and make a statement here about LN nodes.

Regarding what exactly should that statement be? What exactly is unclear? Related to RBF or something else?

The perception that Lightning nodes are difficult to run needs to be addressed. And possibly challenged, if the developer feels that way.

If there were even 1/4 as many LN nodes as Bitcoin nodes, we wouldn't be all gathered here talking about RBF.

[NotATether]

So a quick update, I see the Bitrefill CEO chiming in on the Github issue linked by o_e_l_e_o.

I asked him how he feels about open-sourcing the intelligent double-spending detection tools, so we'll see how that goes. There is a whole year at minimum until mempoolfullrbf default value is changed anyway.

[nz6lngmv]

and saying 0.24 is out and there is nothing WE can do about it is just...

You can let it to default. You can't do much, and you've got to acknowledge that full rbf is the natural state of the network, because ethics are secondary in mining. You can't expect global adoption to come with 0-conf.

why would i have to acknowledge that full rbf is the natural state?
the natural state of network was first seen. that is what satoshi implemmented and there have no good arguments have been presented why would this be bad. people learned that 0 conf is risky and implemented opt-in rbf. some people used rbf and it is a feature of the wallet not the network. And now a thing that worked perfectly fine and is a wallet issue is pushed onto nodes. this thing is pushing the network out of the natural state. incentives were perfectly fine. there is a risk and oportunity to use 0conf and rbf at the same time. a user could choose with their wallet how much risk/convinience they want. Now that chooseing is gone.

"Natural state"

It uses docker which is new and thus needs new skills to acquire and maintain.

Docker is almost 10 years old. Umbrel is made mostly with non-tinkerers in mind who conveniently install 'applications' which automatically run in their own containers. There is not much to maintain.

And now what if it is 10 years old? must i learn to be a mechanical engineer to drive a car? Docker is new and needs new skills.  When my electrs stopped working, there was no more "just installing apps". it stopped working and every tutorial for electrs was no help for me, because i needed first to figure out how do i come to the electrs. In the mean time on umbrel nothing worked. not the blockexplorer, not LN...
I agree that maybe docker is a fine piece of software which helps a lot. At the same time we must also agree that running an umbrel node is fine... until something breaks. And until Dartchoin was on most of the umbrel support chanels, this was also an unpleasant experience.

Buidling on making things easy is something the bitcoin community must work. Ignoring regular (fiat) users is not the way to bitcoin adoption.

[o_e_l_e_o]

the natural state of network was first seen.

It isn't. Since the very first block was mined, even if your node uses opt in RBF/first seen, you still accept full RBF whenever a new block is mined. If a block is mined which contains a transaction which double spends an opted out transaction in your mempool, either you accept full RBF or you fork yourself on to a new network. If there are two blocks found at the same height, and they both contain conflicting transactions, either you accept whichever one is built upon regardless of whether the conflicting transaction was opted in/higher fee/first seen/etc., or again you fork yourself on to a new network. Full RBF is very much the default state, and every node already accepts it. You can do whatever you like to your own mempool, but first seen was never the natural state.

And again, this is only providing an easy toggle option (which is defaulted to off) for a feature which any code could have been using for 10+ years already (and some already do).

[n0nce]

It uses docker which is new and thus needs new skills to acquire and maintain.

Docker is almost 10 years old. Umbrel is made mostly with non-tinkerers in mind who conveniently install 'applications' which automatically run in their own containers. There is not much to maintain.

And now what if it is 10 years old? must i learn to be a mechanical engineer to drive a car? Docker is new and needs new skills.

It's not new in the timescale of technology. It's maybe new for you, but guess how many Bitcoin Core node operators work with Linux and compile software for the first time (running bare-metal).
For most people, working with the command line is new, as well, when they first start a Bitcoin node. So I don't see this as an argument against Lightning or Umbrel.

Besides, you can install electrs (what does this have to do with Lightning?) or Core Lightning bare-metal, too if you wish. It's barely any harder than installing bitcoind manually on bare-metal. (here)

Buidling on making things easy is something the bitcoin community must work. Ignoring regular (fiat) users is not the way to bitcoin adoption.

Do you find installing Bitcoin Core trivially easy for 'regular (fiat) users'?
I mean, I agree with making things simpler, but I believe Umbrel and (what I recently discovered:) Citadel are already doing that. The more they get adopted and used, the quicker they will obviously get bug fixes.

We have this thread for Umbrel troubleshooting, as well: Umbrel — Discussion, issues, solutions

[Wind_FURY]

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.

But average people wouldn't bother run a node even if it's easy to setup. For them, it's more convenient to run lightweight LN wallet such as Electrum, BlueWallet or Phoenix wallet. Even though there are some trade-off depending on software they choose.

If there's an incentive to run a node, then I believe more people will run one. Is it about "human greed"? No, I believe not. It's simply human nature. Decentralization works/has been working in Bitcoin because there's an incentive structure that's making everything stick together. Remove the incentives, then what's the point? Bitcoin cannot be a multi-generational protocol through altruisim. Participating in the network must make practical sense.

[BlackHatCoiner]

If there's an incentive to run a node, then I believe more people will run one.

There's not enough incentive for that. Running a full node ensures you privacy and security, but mainly privacy. Since most people don't care about that, they'll just stick with SPV (which grants them self-custody and security; the significant parts for most). If we want most people to have a full node running, then we should focus on education and on incentivizing for privacy appreciation.

Remove the incentives, then what's the point? Bitcoin cannot be a multi-generational protocol through altruisim.

It shouldn't be altruistic, indeed. Even though it does work altruistically in some parts.

[Charles-Tim]

There's not enough incentive for that. Running a full node ensures you privacy and security

Never mind that this is off-topic. Having your own node using full client or running your own server does not mean your have more security as long as it is connected online. What guarantees security are cold storage and how you avoid being attacked, both online and offline. You can be using an SPV wallet on an airgapped device and have maximum security and also not making use of IP address, but Tor for anonymity. Having your own node, using it with Tor only maximized privacy in my opinion which is enough for some bitcoin enthusiasts to be encouraged to run their own node just like you meant.

[BlackHatCoiner]

Never mind that this is off-topic. Having your own node using full client or running your own server does not mean your have more security as long as it is connected online.

I meant security as freedom of risk from unreliable actors. Not the security of your private keys. If you haven't verified the blockchain, you can't safely assume that what you see is correct.

[PrimeNumber7]

The TL;DR for anyone out of the loop is to implement a new setting for nodes, so that the node treats all unconfirmed transactions in its mempool as RBF enabled, regardless of whether or not that transactions signals for RBF. The default behavior (for now) will be to have this setting disabled, so the current opt-in RBF rules will apply, but nodes will be free to enable this setting and switch from opt-in RBF to full RBF if they choose.

Does this mean that the RBF will be the default only if the majority of node operators enable the setting?  The other question is if this the first step, and  will the default setting eventually become RBF enabled?  Probably too early to say.

Regardless of what the node operators do, the transactions that make it into blocks are entirely up to the miners. It is trivial for a miner to keep track of which transactions it received first, and to ignore conflicting transactions that it subsequently received. If not enough node operators upgrade to have all transactions be RBF, the double spend transactions may not sufficiently propagate throughout the network for the miners to see, however, well under 50% would be necessary for miners to reasonably expect to receive these transactions.

With that being said, it makes little financial sense for the miners to not be on board with this change. All else being equal, it will result in higher transaction fees for the miners.

I would generally be against this change. Others have noted that the change effectively prevents anyone from ever accepting a 0-confirmation transaction, which I think is a net negative for the bitcoin economy. I think this change will also make accepting 1-confirmation transactions (and to an extent, n-confirmation transactions) riskier. If a customer were to receive something of value after one confirmation, if the block that included the transaction is orphaned, and the new block does not include said transaction, the transaction is again unconfirmed and can be trivially double spent. If a merchant is selling a widget worth 1 BTC for 1BTC, a customer could buy widgets from the merchant without loss, and wait for an orphaned block -- or this could be something that is a 'crime of opportunity' in that the customer intended to pay, but when they see a way to avoid paying, they take advantage.

This change will push a lot of bitcoin-related commerce onto LN (and other L2 networks), and I don't think LN is ready for that level of volume yet. My biggest concern about pushing that much transaction volume onto LN is the lack of user-friendly software for sending/receiving transactions, and a close second are the lack of backup options that most software offers.

I do think LN (or some other L2 protocol that somewhat resembles LN) is the long-term solution to the scaling problem and should be used for the majority of transactions over the long-term, but I don't think it is something that should be used *today* for the majority of transactions.

[NotATether]

It uses docker which is new and thus needs new skills to acquire and maintain.

Docker is almost 10 years old. Umbrel is made mostly with non-tinkerers in mind who conveniently install 'applications' which automatically run in their own containers. There is not much to maintain.

And now what if it is 10 years old? must i learn to be a mechanical engineer to drive a car? Docker is new and needs new skills.

It's not new in the timescale of technology. It's maybe new for you, but guess how many Bitcoin Core node operators work with Linux and compile software for the first time (running bare-metal).

He has a point; I mean, none of us instantly became Docker wizards as soon as the technology was first released. There is still a learning curve to follow.

You could be the best Java developer, but if and when [Node]JS comes alone you will have to start learning it from scratch as well.