Topic: Full RBF - page 3. (Read 2502 times)

For illustration, if you set your node to allow 100 connections, then still with only 10% of the network running full RBF, then you now have only a 1 in 37,649 chance of not connecting to one of those full RBF nodes. This way of thinking doesn't tell the whole story though, since the vast majority of nodes on the network do not have 100 connections and just stick to the default of 8. It doesn't really matter if I am 100% guaranteed to connect to another full RBF node, if that full RBF node only has a 10% chance of connecting to another full RBF node, and so on, since any full RBF replacement will not propagate to me despite my good connections. Better to consider the numbers with the default number of 8 connections.

However, my calculations also assume that every large mining pool is only running a single node. Run multiple nodes and it becomes even easier to ensure that you will see a full RBF replacement even with a minority of nodes supporting full RBF.

Indeed its a difficult thing for merchants that rely on Zero conf to sell their products, but, I think Full RBF on the long run is for the benefits of the miners, regarding that the mining rewards of solving a block will soon get to zero, through this Full RBF, miners will have a better reward coming from fees. Instead of neglecting it or allowing zero confirmation, that is, lesser fees or rewards to miners, bad miners could act strange in a way that will affect the network just to earn profits, with Full RBF miners will have a good reason to keep up with their work when the halving reward gets to zero.

To extend this further, anyone can adjust the number of connections for their benefit. By default, if you allow incoming connections you can have up to 125 connections AFAIK (117 incoming, 8 outgoing). If a miner wants to be sure he'll listen to the double-spending, he can establish a connection with every node of the network (as long as it's bandwidth-wise possible of course).

I think projects like bitnodes.io do make use of this kind of network search tricks.

Assuming that the average node defaults to 8 connections, then with only 10% of nodes running full RBF then each node has a 57.0% chance of connecting to at least one full RBF node. If 20% of nodes run full RBF, then that becomes a 83.2% chance. It certainly doesn't take a majority to run full RBF for miners to be relatively certain they will see any replacement transactions.

When considering an individual block, then yes, replacing lower fee transactions for higher fee transactions makes financial sense and will maximize miner revenue. In the long term, however, full RBF will likely serve to reduce the overall fees paid by the community on the whole. If there is no concern about a transaction becoming "stuck", because every transaction can be replaced, then we will likely see fewer people broadcasting transactions at very high fees. They can simply instead broadcast at a much lower fee, confident in the knowledge they can bump the fee at any time if needed. Further, most business which accept zero confirmation transactions only do so if those transactions pay a premium fee, one which is much higher than is necessary at the time. If full RBF ends the practice of zero confirmation transactions, then such high fee paying transactions will also disappear.

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.

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.

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.

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.

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.

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

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.

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)

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

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

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"

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.