Pages:
Author

Topic: Full RBF - page 2. (Read 2265 times)

legendary
Activity: 2268
Merit: 18492
December 19, 2022, 12:11:39 PM
Came across this site via the mailing list: https://fullrbf.mempool.observer. It's been set up by 0xB10C. You might already be familiar with some of the other tools on mempool.observer.

It is essentially keeping track of any transaction which replaces another transaction which is not opted in to RBF. Looks like there are decent number of attempted full RBF replacements with good propagation across the network, but only a few of the replacement transactions are being mined so far. The most convincing evidence of a miner opting in to full RBF thus far is for Luxor, which has a number of replacement transactions showing up in a number of their blocks. Luxor has around 2.3-2.4% of the current hashrate.

I'll be keeping an eye on this to see how things change over the coming weeks and months.
legendary
Activity: 2268
Merit: 18492
December 10, 2022, 02:52:27 PM
I don't think it really makes sense for someone to create a low-priority transaction that is not RBF today.
It doesn't, but a lot of people use wallets which do not support opting in to RBF. In such cases, users are forced to broadcast with a high fee unless they are prepared to wait for however long it takes for 1 sat/vbyte. In a full RBF world, such users can broadcast with any fee they like, with the knowledge they can later bump said fee (using different software if needed) should the mempool suddenly start filling up as it often does.

These businesses often effectively require customers to pay a next-block transaction fee. If a customer is willing to pay this high of a fee for ~instant acceptance by the business, they would presumably be willing to pay a similar fee for next-block acceptance.
But conversely if these customers want to continue having instant acceptance, then they will move to Lightning and can instead open Lightning channels at any time they like in advance, which most will obviously choose to do when fees are low.

I would think that most miners probably use multiple nodes
Almost certainly, especially considering the low requirements needed to run a node when compared to the requirements of a large mining pool. And as I said above, once you start running multiple nodes, it becomes very easy to learn about full RBF replacements.
copper member
Activity: 1610
Merit: 1898
Amazon Prime Member #7
December 10, 2022, 11:03:30 AM
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.
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.
I am not sure if I agree with that logic.

full RBF will mean that every transaction is RBF. Not all transactions are such a low priority for the end user that a minimum fee can be used. If someone needs their transaction confirmed quickly, or within x number of blocks, the transaction fee they will need to include will not change. Today, RBF is "opt-in", and that is true from a technical perspective, but from the end-user's perspective, it is really just a setting, and full RBF will 'require' this setting to be enabled. I don't think it really makes sense for someone to create a low-priority transaction that is not RBF today.


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.
These businesses often effectively require customers to pay a next-block transaction fee. If a customer is willing to pay this high of a fee for ~instant acceptance by the business, they would presumably be willing to pay a similar fee for next-block acceptance.

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.
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.
I would think that most miners probably use multiple nodes, most of which are not known to anyone outside of the entity that is responsible for broadcasting found blocks to the network. Otherwise, they would be at risk of sybil-like attacks.
legendary
Activity: 2268
Merit: 18492
December 08, 2022, 04:41:46 AM
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).
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.
hero member
Activity: 1008
Merit: 508
Leading Crypto Sports Betting & Casino Platform
December 07, 2022, 04:48:04 PM


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.

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.
legendary
Activity: 1344
Merit: 6415
Farewell, Leo
December 07, 2022, 04:47:43 PM
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.
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.
legendary
Activity: 2268
Merit: 18492
December 07, 2022, 04:15:12 PM
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.
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.

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.
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.
legendary
Activity: 1526
Merit: 6442
bitcoincleanup.com / bitmixlist.org
December 07, 2022, 01:31:27 PM
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. Grin 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.
copper member
Activity: 1610
Merit: 1898
Amazon Prime Member #7
December 07, 2022, 11:28:27 AM
#99
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.
legendary
Activity: 1344
Merit: 6415
Farewell, Leo
December 06, 2022, 10:23:53 AM
#98
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.
legendary
Activity: 1498
Merit: 4776
December 06, 2022, 09:59:02 AM
#97
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.
legendary
Activity: 1344
Merit: 6415
Farewell, Leo
December 06, 2022, 08:50:33 AM
#96
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.
legendary
Activity: 2870
Merit: 1794
December 06, 2022, 08:35:48 AM
#95
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.
hero member
Activity: 868
Merit: 5808
not your keys, not your coins!
December 04, 2022, 08:13:30 PM
#94
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. Grin 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
legendary
Activity: 2268
Merit: 18492
December 04, 2022, 10:39:20 AM
#93
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).
newbie
Activity: 5
Merit: 3
December 04, 2022, 10:23:01 AM
#92
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.
legendary
Activity: 1526
Merit: 6442
bitcoincleanup.com / bitmixlist.org
November 30, 2022, 07:05:29 PM
#91
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.
legendary
Activity: 1526
Merit: 6442
bitcoincleanup.com / bitmixlist.org
November 29, 2022, 01:59:03 PM
#90
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.
hero member
Activity: 868
Merit: 5808
not your keys, not your coins!
November 29, 2022, 01:48:56 PM
#89
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?
legendary
Activity: 1526
Merit: 6442
bitcoincleanup.com / bitmixlist.org
November 29, 2022, 01:13:47 PM
#88
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.
Pages:
Jump to: