In case anyone was unaware, mempool.space have implemented an RBF tracker which also tracks all full RBF replacements. You can find a ticker on the landing page, or the full view here: https://mempool.space/rbf
I'm also noticing a lot more full RBF replacements, as well as more mining pools including them, such as AntPool, F2Pool, and Binance pool.
You can read the discussion regarding this change here: https://github.com/mempool/mempool/pull/3867
Topic: Full RBF - page 3. (Read 3060 times)
if i am not wrong, first need cancel transaction, then apply new transaction with new higher fee ?
There is no need to "cancel" a transaction first, and indeed, there is no such thing as cancelling a transaction. All you are doing when you cancel a transaction via RBF is using RBF to replace the transaction with another one which sends the funds back to yourself. If you are then going to send those funds back out with a higher fee, then there is no need to send them back to yourself first. You can just directly replace the existing transaction with your new one. 
if i am not wrong, first need cancel transaction, then apply new transaction with new higher fee ?
Is this possible with FULL RBF?
Yes.I haven't heard of Full RBF yet, and i don't know if it's already implemented in Bitcoin.
You could try actually reading this thread. It is already implemented, but only a minority of miners have currently enabled it.If it's possible, How to avoid double spending?
As I said above - pay a mining pool to include your transaction privately, so by the time it is public it is already confirmed.As soon as you broadcast the transaction, it is not possible to prevent double spending.
Damn, that is actually right. The lowest puzzle is currently puzzle 66 stands at 6.6BTC.
With a normal GPU, it would take about 2000 years to complete the range and solve that puzzle, which is a lot of time.
But with Kangaroo algorithm, it would take literally no more than 2 mins to solve puzzle 66. (WITH KNOWN PUBKEY)
So if you're saying if someone solves puzzle 66 and transfer the coins to other address, someone else can double spend it and take the money for himself instead of the puzzle solver himself? Because once puzzle solver sends a transaction, he will reveal its public key, which other people will crack it back in a matter of seconds with Kangaroo
Is this possible with FULL RBF? I haven't heard of Full RBF yet, and i don't know if it's already implemented in Bitcoin. That is definitly interesting. Imagine working hard for 200,000$ and in the end someone else takes it with absolutely no effort at all, just sends a transaction with a higher fee.
If it's possible, How to avoid double spending?
With a normal GPU, it would take about 2000 years to complete the range and solve that puzzle, which is a lot of time.
But with Kangaroo algorithm, it would take literally no more than 2 mins to solve puzzle 66. (WITH KNOWN PUBKEY)
So if you're saying if someone solves puzzle 66 and transfer the coins to other address, someone else can double spend it and take the money for himself instead of the puzzle solver himself? Because once puzzle solver sends a transaction, he will reveal its public key, which other people will crack it back in a matter of seconds with Kangaroo
Is this possible with FULL RBF? I haven't heard of Full RBF yet, and i don't know if it's already implemented in Bitcoin. That is definitly interesting. Imagine working hard for 200,000$ and in the end someone else takes it with absolutely no effort at all, just sends a transaction with a higher fee.
If it's possible, How to avoid double spending?
People will watch the mempool, check for solved puzzle publickey, solve it quickly with pollard kangaroo and create a new transaction with higher fee.
Someone can already do this and pay a mining pool privately to include their competing transaction over the one in the mempool. Full RBF makes it easier, but it is already possible.If you don't want the public key revealed, then you could also do the same and pay a mining pool privately to include your transaction.
I didn't understand what you mean exactly but when you send a transaction just set it to no RBF, and that's it. If someone attempts to send the coins again, it'll be flagged as a double spend and nodes won't broadcast it to miners
We are specifically talking about full RBF, not opt-in RBF. 
Unfortunately this is no good news for solving the lower bits puzzle transactions
Do you mean those puzzles? Assuming the extreme worst case scenario of a BRC20 spamstorm and the mempool gets clogged for 48 hours, it's not that big of a deal. Just slap a 200 sat/byte fee on the outgoing transaction and it will be confirmed within minutes, literally. Not a problem since rewards are basically over 1 bitcoin by now, so $300 in fees is quite nothing by comparison. 
With 200 sat/byte, it's only $12 in fees. But if someone manages to raise the fee, Kamoheapohea has a point. It will be much more interesting what happens to leaked private keys when Full RBF gets implemented:
Things will get quite interesting once full RBF becomes commonplace. Any such transaction stealing coins from a brain wallet or leaked private key could be replaced by another transaction, regardless of whether or not is opted in to RBF or not. We could end up seeing different bots broadcasting more and more replacements, each paying a higher and higher fee, trying to steal the coins for themselves. Since there is no incentive for any one such bot to surrender and let another bot win, then such transactions could just escalate until the entire value (or close to it) is paid in fees.
I was curious about that scenario too. That would mean that (eventually) only miners profit from funds sent to addresses with leaked private keys.just set it to no RBF
If only you would have read what this topic is about. Unfortunately this is no good news for solving the lower bits puzzle transactions if I understand correctly:
If ALL unconfirmed transactions in mempool are RBF enabled there will an overbidding fight for lower bit-puzzles even if initial transaction has set "NO RBF".
If ALL unconfirmed transactions in mempool are RBF enabled there will an overbidding fight for lower bit-puzzles even if initial transaction has set "NO RBF".
I didn't understand what you mean exactly but when you send a transaction just set it to no RBF, and that's it. If someone attempts to send the coins again, it'll be flagged as a double spend and nodes won't broadcast it to miners
Unfortunately this is no good news for solving the lower bits puzzle transactions if I understand correctly:
If ALL unconfirmed transactions in mempool are RBF enabled there will an overbidding fight for lower bit-puzzles even if initial transaction has set "NO RBF".
People will watch the mempool, check for solved puzzle publickey, solve it quickly with pollard kangaroo and create a new transaction with higher fee.
Can someone confirm?
If ALL unconfirmed transactions in mempool are RBF enabled there will an overbidding fight for lower bit-puzzles even if initial transaction has set "NO RBF".
People will watch the mempool, check for solved puzzle publickey, solve it quickly with pollard kangaroo and create a new transaction with higher fee.
Can someone confirm?
Assuming the extreme worst case scenario of a BRC20 spamstorm and the mempool gets clogged for 48 hours, it's not that big of a deal. Just slap a 200 sat/byte fee on the outgoing transaction and it will be confirmed within minutes, literally. Not a problem since rewards are basically over 1 bitcoin by now, so $300 in fees is quite nothing by comparison.
Unfortunately this is no good news for solving the lower bits puzzle transactions if I understand correctly:
If ALL unconfirmed transactions in mempool are RBF enabled there will an overbidding fight for lower bit-puzzles even if initial transaction has set "NO RBF".
People will watch the mempool, check for solved puzzle publickey, solve it quickly with pollard kangaroo and create a new transaction with higher fee.
Can someone confirm?
If ALL unconfirmed transactions in mempool are RBF enabled there will an overbidding fight for lower bit-puzzles even if initial transaction has set "NO RBF".
People will watch the mempool, check for solved puzzle publickey, solve it quickly with pollard kangaroo and create a new transaction with higher fee.
Can someone confirm?
So with the recent surge in transaction fees and backlog of unconfirmed transaction, there has been a definite increase in the number of full RBF replacements being mined.
While previously we were maybe seeing 3-4 a day, there are now upwards of 20 a day. I'm also seeing more starting to appear in blocks being mined by F2Pool, in addition to those being mined by Luxor.
As before, you can check it out for yourself here: https://fullrbf.mempool.observer/
While previously we were maybe seeing 3-4 a day, there are now upwards of 20 a day. I'm also seeing more starting to appear in blocks being mined by F2Pool, in addition to those being mined by Luxor.
As before, you can check it out for yourself here: https://fullrbf.mempool.observer/
Great! getmempoolinfo works, thanks!
Does anyone know of any command for bitcoind to check whether the Full RBF option is enabled? I just want to get confirmation.
getmempoolinfo should do it. As of 24.0.0, this now includes a field entitled "fullrbf" which returns true or false depending on if you have enabled full RBF.And although I've not tried it, the next time you make a transaction you could ensure it is opted out to RBF and then you should be able to use testmempoolaccept to test whether or not your node would accept a replacement. Or, you know, just actually broadcast a replacement and see that it works.
Alternatively, you could also take a look here: https://fullrbf.mempool.observer/. Find a transaction which as been replaced but neither the original nor the replacement has been mined yet, and then use getmempoolentry to see if the replacement is in your mempool.
After reading a great recap on the matter, I just activated Full RBF on Core 24.0.1 (by adding mempoolfullrbf=1 to bitcoin.conf)
Does anyone know of any command for bitcoind to check whether the Full RBF option is enabled? I just want to get confirmation.
Does anyone know of any command for bitcoind to check whether the Full RBF option is enabled? I just want to get confirmation.
But like what you posted, "most people" don't care about privacy, and validating their own transactions in the network, and actually use Bitcoin.
And that's fine. If you don't want privacy and security, you can stick with SPV. I don't judge you. Running a full node provides minimum to zero contribution to the network; it's rather a personal gain. I'm not gonna force you do something for your own good.The incentive structure is what made Bitcoin actually is today, although some altruism was required to boot-strap the network.
There's enough incentive for the merchant to run both a full node and a lightning node right now. For the former to sleep easy, and for the latter because their clients demand so. Also, you can't have the latter without having the former. 
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.
But like what you posted, "most people" don't care about privacy, and validating their own transactions in the network, and actually use Bitcoin. But if it was possible for a monetary incentive structure placed in Bitcoin for people to their own run full nodes, then "most people" would be making special effort to run one.
The incentive structure is what made Bitcoin actually is today, although some altruism was required to boot-strap the network.
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.
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.
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. 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.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.
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.
Jump to: