Bitcoin Forum

Looks like full RBF will be coming to bitcoin sooner rather than later, and I've not seen any discussion about it yet on the forum.

Here are some relevant links and discussions:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
https://github.com/bitcoin/bitcoin/pull/25353
https://github.com/bitcoin/bitcoin/pull/25373

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.

There are a number of good reasons to do this, including benefits and more security for multi-party funded transactions including coinjoins, Lightning, and other layer 2 solutions. However, it also essentially stops any business from accepting zero confirmation transactions for small values, since all transactions (even those opted out of RBF) could potentially be replaced using RBF.

I'm also curious as to what is going to happen when (for example) 50% of nodes have enabled full RBF, 50% of nodes have not enabled full RBF, and I try to replace a transaction which is opted out of RBF. What about if I'm using a hot wallet and not my own node? Will I have to connect to different servers to find one which will relay my replacement transaction? And then presumably some block explorers will show the original transaction while some will show the replacement, and I'll have no idea which one will actually get mined until one of them is mined?

It is likely that most nodes will implement the Full RBF and here are my reasons:
The mining Nodes will benefit in this aspect because having transaction default with Full RBF allows signers to boost transactions with more fees whenever the mempool becomes congested making them earn more sats from transactions fees.
There is also a high chance that other SPV wallets will follow the adoption just to keep their customers in the circle so that they don't move to other hots wallets that run their own nodes with full RBF feature for users but how soon I can't say.


If a transaction has been flagged as RBF by a node, does block explorer has the ability to exclude it from transaction details? If the node you are connected has an RBF enable, that shouldn't be a problem with any explorer or is there going to be a change in RBF when nodes relay transactions within the network?

What I am thinking too, also just because of what you stated already, it will also help the mempool to be less congested as some people will be able to pump the fee and increase the chance for the unconfirmed transaction'to be included into a block.

But that is not what o_e_l_e_o is asking. Even if 90% nodes signal for it, there will be a time at the start that just less than 50% nodes will signal for it and the number of nodes that will be signalling it will be increasing. If it is 50% to 50% of the nodes that signal and that do not signal, that it is possible some transactions in the mempool of the signal nodes to flag the transaction as RBF while those that did not signal will have the transaction as non RBF. So which one will be included into a block and be confirmed?

Yes, just like https://www.blockchain.com/explorer?view=btc do exclude it while some do include it. The thing is it is possible an unconfirmed transaction which is non RBF will be flagged as RBF on some mempool (mempool of the nodes that have signalled for it already) and remain not flagged as RBF on some other mempool (mempool of the nodes that have not signalled for it).

I guess that for a while there may look like a lottery. A replacement transaction of a non-RBF may have a bigger (than 50%) chance to get rejected even if 50% of the nodes are using the new code (unless I misunderstood something). But it should be pretty much okay, we do know that if we want RBF it should be signaled and we do know that a transaction cannot be trusted unless it's mined.

And I do think that after this implementation (when the vast majority will have it in use) the way the mempool works will be more predictable.
Yeah, it's a somewhat bad news for the services that were boasting 0-confirmation deposits. But they can use LN now.

Most SPV wallets, such as Electrum, do not run their own nodes. It will be entirely up to the individuals running Electrum servers whether they enable full RBF, or leave it turned off (as is the default). There will also be plenty of nodes running older software and plenty of nodes who simply don't bother to enable it because they don't see the point, can't be bothered, are unaware of the change, etc. We will probably get to a network wide enabled scenario eventually (if not through individual nodes enabling it then through it becoming enabled by default in future versions), but we must still move through the part-enabled part-disabled phase to get there.

The transaction won't be flagged as RBF by a node. A transaction is only ever flagged as RBF by the person who creates that transaction. Nodes with full RBF enabled will treat all transactions as RBF enabled even if a transaction is not RBF flagged.

That wouldn't have made a difference. Read from "# 2nd issue : RBF opt-out by a Counterparty Double-Spend" on this link: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html. The very ability to broadcast a non-RBF transaction, whether or not some wallets use it by default or not, creates an attack vector for such transactions.

Speaking from personal experience, the number of merchants I use which accept zero confirmations for low value transactions is much higher than the number of merchants I use which use Lightning. I suppose this change will force them to adapt.

If you use light wallet and managed to connect to server which relay full RBF transaction, it's likely your transaction will receive on miner mempool. Each node connect to at least 8 other node, so in average 4 of them will continue to relay your transaction.


It's also bad news for user who only occasionally spend their Bitcoin on such services. It's unlikely they'll bother use LN wallet or lock their Bitcoin on LN channel when they only make transaction once in a month.

I didn't see much talk about this RBF news outside bitcointalk forum, maybe because everyone is talking about crash and bear market now  :P
I think there is a good chance that companies and regular members will rather accept Lightning payments for smaller values instead of using Bitcoin on main chain.
Fees are smaller this way especially during the time when there is congestion in mempool like we saw recently.

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.



I read the post by Antoine Riard, much of the technical stuff is over my head.  I'm not sure how RBF adds security to Multi-Party transactions, is just to get people used the fact that a transaction isn't guaranteed (or on it's way to becoming guaranteed) until there's at least one confirmation?



For brick and mortar shops who've been accepting bitcoin already I don't think this is a big deal as most people tend to be honest when dealing locally and face to face.  For online retailers it may be an issue if they're selling digital items that customers want to download instantly.  As LN becomes more and more common, it'll become a non-issue.



This is an interesting question.  It seems like it's up to the node operators to enable this feature, and it's purely democratic i.e. it'll take a majority of nodes enabling the feature to make the whole network full RBF.  Am I correct in my understanding?  Or will clients be able to pick and choose regardless of how may nodes enable the feature?

I don't really have experience with that, I use RBF even when I shouldn't really, so I am used to wait for confirmations.
If the use of LN is that good, that's a good news.


Good point. People will have to wait for at least one confirmation if they go on-chain.
If I'd do that I would at least consider using a custodian LN wallet (like blue wallet). Not a perfect solution, but it does the job once in a while.

The default is for full RBF to not be enabled. Individual nodes can choose to enable it for transactions in their mempool, but if I enable it and you don't, then you will continue to run with the current opt-in RBF rules. Even if every other node enables it and you don't, then you will continue to run with the current rules.

I think almost certainly yes.

Here is the relevant section. I'll try to simplify it below:

Consider any transaction which requires inputs from more than one party. Coinjoins and Lightning channels are the most common examples. I can DoS such a transaction by providing my input, and then while all the other inputs are being collated, double spend that input in a non-RBF transaction, meaning the original transaction will fail and the other parties will all have wasted their time.

The next step up is to consider your layer two client which is connected to your node. You submit the Lightning channel transaction (for example) to your node, but I'm already spreading my non-RBF double spend through the rest of the network. Your client then repeatedly tries to use CPFP to bump the fee since it just sees the transaction not confirming, at which point I can invalidate my non-RBF double spend by replacing an RBF enabled unconfirmed parent, allowing your transaction to propagate and forcing you to pay the full excessive CPFP fee.

This could become a serious issue if various wallets, services, platforms, etc. decide to start DoSing their competitors in order to attract business to themselves.

No. This isn't a case of signalling for a network wide change, but rather a case of node operators choosing the behavior for their own node.

Why don't we utilize first-seen-safe RBF (https://github.com/bitcoin/bitcoin/pull/6176) then? If the problem is to annoy the other party/parties by cancelling the CoinJoin or channel opening transaction, we can give a solution by accepting only transactions that spend to the same outputs, equal or greater amounts.

I don't understand this part. Since you've let a non-RBF transaction been propagated, how can you cancel it with an RBF unconfirmed parent?

If I have got o_e_l_e_o correctly:
The non-RBF transaction is invalidated with double-spending its unconfirmed parent (which is RBF-enabled).
With invalidating the parent, the child (which was spending the same UTXO as the coinjoin transaction) is removed from the mempool and the coinjoin transaction can be propagated and confirmed.

I might be missing something too, but I don't think the purpose is merely to annoy/harass the other parties, but to delay confirmations until the RBF/CPFP algorithm gets close to maximum fee range, then the attacker sends his own RBF transaction and forces everyone to pay that high fee.  The attack vector would require a a miner with a lot of hashing power to take advantage of the attack.  I don't know how practical/profitable of an attack vector it really is, I mean if the miner's equipment is as finicky as mine I'm sure he's got bigger fish to fry.

With FSS, if the rest of the network sees my malicious double spend first (which is how the attack takes place), then they will refuse to replace it even with the higher fee paying multi-party transaction (coinjoin, Lightning channel, etc.)

hosseinimr93 is correct. For further expansion:

I make Transaction A, which spends UTXO 1 and creates UTXO 2, and is opted-in to RBF. I then use UTXO 3 to join a multi-party transaction. At the same time, I make Transaction B, which spends the unconfirmed UTXO 2 and UTXO 3 and is opted-out of RBF, and broadcast Transaction 2 to the rest of the network. As the rest of the network has seen Transaction 2 first, which is non-RBF, they consider the multi-party transaction to be a double spend and reject it. Once the affected party has maxed out their fee reserves with repeated CPFP attempts, I can then replace Transaction A (which is RBF enabled), send UTXO 1 somewhere else which means UTXO 2 no longer exists, means Transaction B is now invalid, frees up UTXO 3 to be used by the multi-party transaction, and the rest of the network will now accept the multi-party transaction and its excessively high fee paying CPFP children.

It can be either - wasting time or wasting fees.

It doesn't require any mining power at all. The attack can take place as I've described just above in this post.

Wait, if I don't upgrade my full node to a newer version, I am risking getting an incomplete (wrong) version of mempool and, therefore, won't be able to verify independently everything that happens in the blockchain? It all sounds like, with this change, we are doing intentional hardfork forcing everyone to upgrade to modified software, albeit without changing consensus rules. That still may cause network partition and a decrease in decentralization because part of the nodes (pre-full RBF ones) will lose their status as being considered full nodes since they no longer will be able to conduct full verification of valid transactions.

Even if some nodes don't enable full RBF, there won't be any new chain and we won't have any hard fork.
It's possible that a transaction exists in a mempool while it doesn't exist in another mempool, but all nodes will still have the same blockchain.

Here's the way I see it:

Let's say Alice does not enable full RBF, but Bob does. Carol broadcasts a transaction which is not opted in to RBF, which propagates to both Alice and Bob's mempools. Carol then broadcasts a replacement transaction. Alice, running the old rules, rejects the replacement transaction as a double spend, while Bob, running the new rules, accepts the replacement transaction as an RBF. Alice therefore has the old transaction in her mempool, while Bob has the new transaction in his.

At some point, one of these two transactions will be mined in to a block. Which one is mined will depend on a variety of factors, such as how many nodes are running the old or the new rules, how much hashrate sees the original transaction or the new transaction, the fees both transactions pay, which miner is lucky enough to find the next block, and so on.

Once the next block is found, then all nodes, regardless of which rule set they are using, will be able to validate the transaction which was included in the block, and if necessary, remove the other one from their mempools. If the original transaction confirms, full RBF enabled nodes like Bob will eject the replacement, and if the replacement confirms, full RBF disabled nodes like Alice will eject the original.

The only problem is that Alice verifies the confirmed transaction post factum, and, therefore, plays less significant role in enforcing the consensus rules. If all transactions are to be replaced using full RBF rules, then Alice is basically cut off from the rest of the network.

This was the primary way of RBF at that time when there were plans to either get FSS-RBF or Opt-in RBF on the network. There are many different risks and hassle with FSS-RBF, namely with it being subjective to the different miners and that it provides a false sense of security with no security benefits whatsoever. It was only adopted by Discus Fish (AKA. F2Pool) and dropped shortly afterwards. RBF (Opt-in or not) does not prevent fraud or anything like that, merely making it slightly harder for the average person but doesn't make them immune.

I don't foresee it to be a problem. Users generally do update their nodes, and currently 18% of the network runs 0.23 and 50% of the network runs 0.22. The number of hops that it takes to reach a miner should still be acceptable and you shouldn't have a case where it gets stuck due to nodes stopping the propagation of the transaction. Miners are generally very well connected to a myriad of nodes. However, the main concern should be whether the miners are willing to change their policy and start accepting these kind of transactions.

Peering should be a no issue because it is usually done by recognizing the service flags of their peers. It shouldn't be too difficult to have a service flag where the node attempts to connect to another which has full-rbf enabled.

That's unfortunate, I do like the occasional zero confirmation transaction that's instantly accepted.

RBF doesn't empty mempool, for every transaction that gets into a block because of the increased fee, there's another transaction that doesn't make it anymore.

Isn't that the same now? If you use RBF, there are 2 valid signed transactions out there, and it's up to the miner to choose which one to include. The one with the highest fee is most likely to get confirmed, but there are no guarantees.

I admire your confidence in people's honesty :) And even though I agree most people would be honest, I fear this would attract dishonest people who see an opportunity to scam a shop.

I think that after the change this should be more predictable (but still not 100%). Since a new tx is treated as RBF (maybe if it has bigger fee though?) it should have "the upper hand" when picked by miners.
Of course, since one's mempool is different from other's, the chance for the initial tx get confirmed first, even if the second one has the bigger fee, cannot be reduced to 0.
Isn't it the same now with all the tx that have RBF flag on?

I confess that I'm still confused.

In this case, shouldn't the CoinJoin/Lightning software warn for unconfirmed parent(s)? I wouldn't accept a non-RBF transaction which has an unconfirmed RBF-enabled parent as "settled".

You mean can't be propagated and confirmed?

You mean Transaction B? You haven't mentioned of any Transaction 2.

Isn't compulsory RBF benefiting miners? Why wouldn't they want to change their policy accordingly?

Very marginally. Most of the transactions shouldn't require RBF especially with periods of low fee rates and low fee volatility. Miners are known to be fairly slow at signalling support for various different protocol upgrades so that by itself already means that there is low incentives when there isn't a lot of tangible impact to their own earnings. It does come with some testing and manpower which can be insufficient for them to really change it.

I'm not saying that they won't do it, but then there will definitely be time lag.

The UTXO used in the coinjoin transaction doesn't have any unconfirmed parent at all.
That UTXO was combined with another UTXO in a different transaction at the same time as the coinjoin transaction. This is the transaction which was invalided with doubling-spending its parent.
As both transactions have been made at the same time, it's possible that the client see the coinjoin transaction before the other one and doesn't understand what's causing the issue.
This is my understanding from o_e_l_e_o's post and I really don't know how likely this is.

Me too.


No.

If each of the inputs that are used in the RBF-disabled CoinJoin don't have an RBF-enabled unconfirmed parent, then what's the problem?

The CoinJoin transaction is consisted of some parties' inputs. One of those inputs might be an RBF-enabled unconfirmed parent, which can be abused by an attacker to disrupt mixing. Can't you give a solution to this if you make CoinJoin unavailable for RBF-enabled unconfirmed inputs?

I must have messed things up.

The coinjoin transaction is using UTXO A and is non-RBF. UTXO A doesn't have any unconfirmed parent and there is no problem here.
There's another transaction made using UTXO A. In this transaction, there's another input which is UTXO B. This transaction is also non-RBF.

The two above transactions have been made at the same time. So, some nodes (including the other party of the coinjoin transaction) see the coinjoin transaction first and some nodes see the other one first.

The transaction that has created UTXO B is still unconfirmed. This transaction has been flagged as RBF. As this transaction is RBF-enabled, the sender can easily double-spend that.
With doing this, the transaction spending UTXO A and UTXO B is invalidated and now the coinjoin transaction is the only transaction that uses UTXO A. Now, the coinjoin transaction can be propagated and confirmed without any problem.

Note that the attacker isn't trying to invalidate the coinjoin transaction at all.
The attacker is only trying to force the other party to pay more fee for the coinjoin transaction. (The other party doesn't know what's causing the issue and think that the problem is with the low fee.)

Again, this is what I understood from o_e_l_e_o's post and I think it's very very unlikely that the attacker can succeed.


From my understanding, this is not the case here.

Let me sum things up.

We have transaction_1. It is non-RBF, it uses UTXO A as an input (along with others) and it's a CoinJoin transaction.
We have transaction_2. It is non-RBF, it has two inputs; UTXO A and UTXO B.
We have transaction_0. It has RBF enabled, it creates UTXO B, it's currently unconfirmed. We call this the parent of transaction_2.

We send transaction_1 in node_1 and transaction_2 in node_2 at the same time.
The network is split to those who have transaction_1 and to those who have transaction_2 in their mempools.

One of the CoinJoin makers wants to speed up the confirmation (of transaction_1) and does CPFP.
The attacker sees that CoinJoin is overspent in fees and reverses transaction_0.
Now that transaction_0 is invalidated (because it's opted-in to RBF and is double-spent), transaction_2 is also invalidated, because it's its child.

Now (all) nodes have transaction_1 in their mempool, but it's overspent in fees.

---

Is that correct?

Yes.

---

The thing I don't understand is how the attacker can manage to do this and that's why I said it's very very unlikely.
For being successful, it's needed that majority of nodes see transaction_2 first and the honest party (the one who does CPFP) sees transaction_1 first.

The thing I don't understand is why can't the software (of CoinJoin or Lightning) warn the users for RBF-enabled unconfirmed parents. If the users are afraid of being victimized in this way, they only have to avoid dealing with inputs whose parents are RBF-enabled and unconfirmed.

I'm not convinced that this change will have a good impact, unless there's another danger I haven't thought of (or understood). Sure, nodes could replace non-RBF transactions since 2009 if their owners changed the source code, but it feels like we're now moving into something else.

I guess the attacker knows the victim's node URI?

The inputs used in the multi-party funded transaction (MPFT) are all confirmed. While the MPFT is being created, a malicious party can double spends their input to prevent the MPFT from being broadcast. This double spend can include a different input with an RBF-enabled unconfirmed parent, which allows the double spend to be easily invalidated in the future.

Yes, you've got it now.

Because, again, the inputs to the MPFT are all confirmed. It is only the malicious double spend which has the unconfirmed parent, which will obviously not be known about at the time of creating the the MPFT.

Here is another post from Riard in the mailing list which explains things in yet another way: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020595.html

Here is an example of this attack happening on a Wasabi coinjoin (on testnet) which developer /dev/fd0 just shared with the mailing list and on their Twitter:


You can see the double spend transaction here: https://mempool.space/testnet/tx/a57e46e8a69752802ca83caa37b32bebcaa2965b5572fa805f2b48f1846fd3df
The third input in this transaction for 0.00006561 tBTC was the same input which was used in the attempted coinjoin transaction as you can see from the screenshots.

The Wasabi client reported the invalid coinjoin as "broadcast".

I see the problem. The CoinJoin makers have to either bump their fees with CPFP or have their CoinJoin rejected. So, how does mandatory RBF help the situation? The attacker wants to make us spend more in fees or delay our mixing.

• Suppose we have Alice, Bob and Carol, with their respective inputs A, B and C.
• Carol is the attacker.
• Alice, Bob and Carol sign the CoinJoin transaction, and it's ready to be broadcasted.
• Carol has signed a transaction wherein she replaced CoinJoin with her reversal.
• Both are broadcasted, but Carol's transaction replaces the CoinJoin.
• Alice and Bob can either raise their fees or let Carol's replacement transaction become confirmed and create another CoinJoin later.

Can't we implement some sort of OP_IF, OP_ELSE penalty mechanism for this matter? It'd increase the transaction fee, though.

By making it far more costly an attack to perform, and by giving the coinjoin transaction the ability to overcome the blockage.

At present, Carol can attack by broadcasting a non-RBF transaction at 1 sat/vbyte. It doesn't matter what fee the coinjoin pays; the malicious double spend will not be replaced. With full RBF, Carol must be willing to pay a much higher fee. If she only says 1 sat/vbyte, then the coinjoin can be bumped to an equivalent of 1.1 sats/vbyte and displace her malicious double spend. Further, at present, Carol can leave her 1 sat/vbyte transaction in the mempool as long as she wants, and let the coinjoin operator repeatedly attempt to bump the coinjoin with a higher and higher fee, with effectively no limit (other than the limit of what the participants would find acceptable). With full RBF, the coinjoin operator only ever needs to bump the fee as high as the fee on Carol's double spend (+ 0.1 sats/vbyte).

I don't see how you could. By the time you come to punishing Carol for it, she has already achieved what she wanted to achieve - wasting the time and/or money of the other participants.

Isn't that risk inherent of "joining" your transaction with someone else's? I don't really see how this is a problem: if a part of the "joined" transaction becomes invalid, I assume the coinjoin can just recreate a new transaction without that input and broadcast it again, right?

Right.

She won't dare to cheat if a fairness protocol she uses disincentivizes her do so. I can neither think of a script that does it, I was just saying. Even if there is, that I doubt, it'll increase the size of all CoinJoin and Lightning transactions, making things more costly to operate.

While I do acknowledge the problem here, I don't like that a possible attack on CoinJoin or Lightning transactions can be resolved only by enforcing a rule on all the transactions. Point of sale unconfirmed transactions become less attractive for the merchants, pushing them to adopting off-chain solutions. The question is if, say, Lightning is ready to be adopted by every merchant. I was thinking of a rather slower and smoother transition.

Trying to see if BitPay will make allowances for this then finally but don't see anything to suggest it on their site -- In fact, the latest RBF threads updated in June on their FAQs still show you how to disable them.

They've been forcing people to overpay on fees (and rejecting RBF-enabled ones so you're forced to finalise a fee), one of the few things I put up with for the sake of spending that Bitcoin on pizza where I live. Or is that merely merchant settings on their end of BitPay?

I see this as a win, maybe one reason it's happening? To push merchants to accept a tool designed to help users compensate for miscalculations?

Maybe. Or maybe a malicious attacker (maybe some other coinjoin wallet who wants to attack their competitors) is flooding your coinjoin service with inputs that they are double spending, so it happens again on your next attempt, and your next one, and your next one, rendering it impossible for you to coinjoin any coins at all. The same could apply to any custodial Lightning wallet, as another example.

But it is neither a rule nor being enforced. This is a change with the Bitcoin Core software, not the Bitcoin protocol, giving node operators the easy option to accept replacements for all transactions in their mempool. Node operators can already do this if they wish, and some alternative full node software (such as Knots) have had this option for years already.

This is my main concern too.

Given how long it took BitPay to get on board with things like segwit, then there is exactly zero chance they are going to react to upcoming changes before they have even been finalized yet, let alone released.

Any merchant who's using BitPay should switch to BTCPay Server the soonest possible. It doesn't make sense to use an intermediary for this purpose when the currency's software already exists for eliminating this kind of third parties.

I have never used BitPay, but I'd read somewhere that they even demanded KYC for a purchase. Unbelievable or just reasonable and probable considering today's sniffing standards?

It isn't enforced, but having it as an option officially on Bitcoin Core rather than as a potential change that requires altering the source code:

• Encourages the miners to switch to it.
• Creates a fine mess on the network, defeating essentially the purpose of non-RBF; especially due to the former.

This will indeed be the beginning of the end for non-RBF transactions, as I suspect before long most miners will choose to look at mempools which have enabled full RBF to allow them to maximize their profits from fees. I guess zero confirmations transactions will be a thing of the past unless the two parties involved completely trust each other.

Here are the final commits to be merged in to the main branch: https://github.com/bitcoin/bitcoin/pull/25353/commits

If all goes to plan then this will be live in the next version of Core, 24.0.

We can, and it currently exists. It is called SIGHASH. So, by signing your CoinJoin with SIGHASH_ANYONECANPAY, you sign only your input, and all outputs. That means, Alice and Bob can detach Carol if needed, and attach some other source of coins, but then the destination has to remain the same (which means Carol will be paid, so that's not the solution). Because if you have CoinJoin, you have to sign all outputs, if you sign only some of them, then you have no privacy boost, because it is possible to link your coins.

So, to solve the problem of CoinJoin, there is a need to construct transactions in a non-interactive way (and to provide that, transaction joining (and splitting) needs to be implemented). A good start is SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, each participant could sign a single input and a single output in this way. What is needed, is taking N such entries, and make signatures in a way, where they could be turned into SIGHASH_ALL, to be indistinguishable from any normal transaction. It is about joining and splitting one-input-one-output entries, where all participants can do that, but if things will finalize, then they will look like any ordinary SIGHASH_ALL transaction.

I still don't think that solves the problem. Even if we ignore the fact that contributing one input and one output makes it almost trivial to deanonymize you simply by matching output amounts to input amounts, then Carol can still attack the process. Even if the other parties can simply remove Carol's contribution to the transaction and try again, then she has still succeeded in wasting their time. A large enough entity (think another coinjoin provider attacking their competition) could easily spam enough inputs to make this happen over and over and over.

Bump.

There's been another recent flurry of discussion regarding this on the mailing list and GitHub, which stemmed from this post by one of the developers of Muun wallet: [Opt-in full-RBF] Zero-conf apps in immediate danger (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020980.html)

His concerns are essentially that full RBF means all their zero confirmation functionality, include submarine swaps and various instant Lightning sends, become too risky and they would have to cease immediately. This spawned a lot of discussion which you can read if you are interested. There is a good summary of the whole issue from Gloria Zhao available here: https://github.com/glozow/bitcoin-notes/blob/full-rbf/full-rbf.md

The discussion spawned several more pull requests:
https://github.com/bitcoin/bitcoin/pull/26287 - remove the full RBF option from 24.0 entirely, and potentially introduce it in 25.0 with a default setting of true
https://github.com/bitcoin/bitcoin/pull/26305 - leave the full RBF option in 24.0 with a default setting of false, and turn the default setting to true in 25.0
https://github.com/bitcoin/bitcoin/pull/26323 - leave the full RBF option in 24.0 but change the default setting to true, but it does not activate until May 1st, 2023
https://github.com/bitcoin/bitcoin/pull/26438 - remove full RBF option entirely

It's not clear yet what the final outcome here is going to be. There seems to be consensus for the full RBF option defaulting to true at some point in the future, but not clear yet if that will be 25.0, a future version, a fixed date 6/12/18 months in the future, or some other point depending on network uptake. Whether or not 24.0 still ships with the full RBF option included but set to false by default is not so clear at the moment, but I suspect it will go ahead as was originally planned.

Pretty searing discussion there. Essentially and summarily, there are mainly two groups; those who find it only theoretically possible to have zeroconf transactions double-spent, and those who find it both practically and theoretically possible.

Pro-full-RBF users' arguments are:

• It's the natural state of the network.
• It's a false sense of security, because miners must be considered to always have full RBF enabled, because they follow profit.
• Defends against CoinJoin and Lightning related DoS attacks.

Pro-postponing-full-RBF users' arguments are

• Some businesses accept zeroconf as settled, and must either move to Lightning or withdraw this policy.
• Lightning and CoinJoin software needs upgrade.

(Anti-full-RBF users' arguments are mostly invalid IMO, especially due to complete dependence of transaction fees after a few decades)

---

---

I'm of the latter. We should postpone it for a little longer, at least until significantly used wallet software such as Muun upgrade. Most Internet-based businesses will have to switch from zeroconf to Lightning this year.

v24.0 is about to be released and is almost off the assembly line so I don't see them making a last-miniute change to that release considering the kind of peer-review process PRs get and the deterministic building procedure for each release. Any change will likely affect v25.0 at the earliest.

IMO, part of the issue is that if we take this forum as a small microcosm of bitcoin enthusiasts this post about Full RBF in 4 months got a whopping 44 replies.
People are not paying attention to it, and the people who are using software that is going to be effected by it seem to be taking their time in dealing with it.
Should they have been more proactive? Probably. Is it important that we start Full RBF now, nope not really (at least in my view).

I am on the side that would like to see them deal with this a different way, but my way would probably cause more issues for non tech users and generate about eleventy billion lines of spaghetti code so there is that.....

-Dave

The problem with disabled RBF is that it relies on Bitcoin users' sincerity for transaction settlement, oppositely to RBF, which relies on miners' profit. Running a full node does grant you an opinion, because you're enforcing both consensus and non-consensus rules, but you should not rely to the latter. Miners can, and should, dump non-RBF double-spends, but I hold no sway to the way they'll choose to do business. Ultimately, they decide if they'll put profit above this pseudo-rule.

Disabled-RBF Is fundamentally flawed, because the system is designed to work trustlessly, and transactions that pay the most ought to, naturally, have advantage.

Marco Falke noted that in his pull request here: https://github.com/bitcoin/bitcoin/pull/26287. Full RBF has been discussed for years. It's pretty surprising that developers of projects which accept/depend on zero confirmation transactions are only learning about it now.

Lots more discussion on this pull request (https://github.com/bitcoin/bitcoin/pull/26438) in the last couple of days, and now another new one from Andrew Chow - https://github.com/bitcoin/bitcoin/pull/26456.
This one removes the setting from 24.0 entirely simply to allow 24.0 to be released and to allow ongoing discussion regarding full RBF to happen, but even that seems to be contentious.

As noted in the mailing list discussion, this is the natural state of the system, and as the block subsidy falls and fees make up a larger and larger proportion of miners' income, then they are more and more likely to start accepting higher paying replacement transactions even if the original is opted out of RBF.

I have a feeling that the services relying on non-RBF transactions may have a small edge / advantage over the competition (since 0 conf is a good advertising and attracts users) hence they're not eager to change.

So while it could be a nice gesture to postpone the full RBF a little, we may have the exact same problem on the next release too.

Absolutely, but I think it is the right thing to do for two reasons. I understand the points that this is only a setting which is defaulted to off, and actually any node or miner who wants to run a full RBF policy can do so at any time even without this setting. However, I don't think it is right to release a feature which has divided opinion so strongly without spending a bit of time working things out, and it would also give the developers and services which seem to have been caught off guard by this change some more time to react. Although this has been discussed for years, and the developers in question really should have done a better job of keeping up to speed with ongoing developments, I don't think it's a good look for the community to now say "Well, sucks to be you" and release a feature which some developers are saying will completely break their app/software/business model.

Now, as I said above, full RBF is the natural state of the system, not to mention the necessary benefits it brings to allow further development of Lightning and other projects, and so I fully expect it to arrive in v25.0 if not in v24.0. But I don't think delaying it from v24.0 is necessarily a bad thing, and if we did, then hopefully by the time v25.0 comes round many of these issues would have been discussed and resolved.

So looks like all the pull requests linked to previously have now been closed, meaning that 24.0 will ship as originally planned with the mempoolfullrbf option present but default set to false. And with 24.0 being bumped to rc4 (https://github.com/bitcoin/bitcoin/pull/26475), we are probably only a few days away from release.

Will be interesting to see what the general mempool policy turns out to be and how quickly nodes and miners start enabling the option. There is already some financial incentive for miners to start adopting full RBF, not just from people attempting to replace non-RBF flagged transactions but also from this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021143.html

I suspect we will pretty quickly start to see services which offer zero confirmation deposits or payments stop doing so. I suspect there will also be a handful of services which are unaware of this change being scammed.

I don't expect node operator bother change default option. It's already proved with lack of node which accept transaction with fee lower than 1 sat/vbyte or non-standard transaction.


Starting from $100/block? It's rather generous considering coming from an individual.

I also think the majority of non-mining node operators probably won't bother to change the default, but that is different for mining node operators. All it takes is one large miner to start enabling the setting on all their nodes and start claiming the additional rewards for other miners to want in on that too. And with the success of things like transaction accelerators, a miner could offer their services out to the community and invite people to broadcast RBF transactions directly to them so they know they are getting seen.

It will be a bit haphazard to begin with, but I suspect that prior to the setting being changed to true by default in future version that we will effectively be running a full RBF system across the network already.

My 2c:

Full RBF is the only option that makes sense.

The RBF behaviour is not part of Bitcoin, it's just a node implementation detail.
Anything prior to consensus is not sacred. As long as a block follows consensus rules, it is valid, regardless of what transactions it includes from the mempool.

This is a key difference between Bitcoin and the shitcoins.
Bitcoin doesn't try to get fancy implementing all kind of "social consensus" rules and other such stupid non-deterministic things.

Users expect determinism and reliability out of the Bitcoin network. There should be no features which rely on the goodwill of node operators.
This would be akin to building an extension to your stone fortress out of paddlepop sticks.

The same goes for any feature which attempts to treat the mempool as sacred.
The mempool is a resource to be plundered in the greediest way possible. It is a Herbalife salesperson's phonebook.
Any implementation details which try to get nodes to treat mempool txns in a particular fashion is foolish.

Miners ought to order transactions by fee revenue and nothing else, otherwise they are in the wrong industry.
If there are 50 pending blocks, and I submit a transaction with a higher sats/vb than the rest, rational miners should include my transaction first before all the others even though my transaction is the newest.

I agree, but as I said above, it is obvious that many entities and businesses which depend on risk assessed zero confirmation transactions for much of their functioning were caught unaware by this change. Now you can argue that is their own fault, since this has been discussed for years, but I don't think it would be wrong to give them more time to adjust their inner workings to be compatible with this change.

Having said all that, though, it isn't going to happen. 24.0 has already been finalized (https://github.com/bitcoin/bitcoin/releases/tag/v24.0) and will be released with mempoolfullrbf as planned, and yet another pull request (https://github.com/bitcoin/bitcoin/pull/26525) to revert it has been fairly widely NACKed.

True, but in this case, Knots has supported full RBF for a long time now, and if a Core node really wanted to run full RBF they could do that too with very minimal code changes. Relying on zero confirmation transactions has always had an associated risk, and was always dependent on nodes not implementing full RBF, which they could have done at any time.

Well now they have at least another year to decommission their zero-conf transaction scanning, and move to Lightning Network instead. All the major payment gateways support it, so I see no reason why an in-house solution shouldn't be able to do the same.

Exactly, but that's not bad. Merchants and customers should rather rely on the good will of their between relation, not on the Bitcoin network. If a customer is malicious, it doesn't matter much if most nodes choose to not propagate transactions that double spend an RBF-disabled transaction; he's surely discouraged to try, but there are alternatives such as miner bribing.

On the other hand, if there's a good relation between the merchant and the customer, regardless of whether the transaction opts-in for RBF or not, there won't be double-spends. And I don't know about you, but I mostly have good relations with those I transact with.

---

---

Question: how hard is it to full the network with nodes that have Full RBF? Could you setup multiple full nodes in one machine without anybody knowing one person is running all?

Sure, but you also have to consider entities such as Muun wallet or Bitrefill which have tens or even hundreds of thousands of users. Impossible for them to build a relationship with each one. (I named these two specifically since they were involved in the above linked discussions on GitHub and the mailing list.)

Sure, but it wouldn't really achieve much if almost every other node continues to run opt in RBF and rejects all the replacement transactions you broadcast. Or more to the point, unless major miners update their nodes to start accepting full RBF replacements.

I don't see the big deal with Bitrefill. I use them on almost a daily basis now that they have bill payments too. Waiting for a confirm for a GC is not a big deal, and payments seem to go out overnight anyway.
RBF / no RBF I don't see why they would be caring that much either way anyway. Have to go read what they have said.

I understand what they are trying to do and why they are trying to do it, I just think as do some others that we would be better off drawing a line in the sand and saying as of THIS DATE (or block number) it is happening. That one last warning so to speak.

-Dave

Yes, indeed. I was referring to smaller businesses, which are more in number. Bitrefill, as a successful business, ought to switch to lightning.

More nodes that have Full RBF means more chances for everyone to establish connection with nodes that have Full RBF. Therefore, more chances for an attacker to take a user's transaction and hand it over to the miner.

They already support Lightning. But as per their CEO's post here (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html), Lightning transactions only make up around 15% of their business, while zero confirmation transactions make up 60%. This is a huge disparity. It's not enough to simply say "Use Lightning", when probably the majority of those 60% either have no experience with Lightning or aren't even holding their own coins at all.

Yes, but that doesn't matter if the miner in question is running their own node(s) which have full RBF disabled. Their nodes will reject such a transaction, and so the miner won't include it.

Right. I'm buying gift cards frequently from that place.  :P

Ouch! People, justifiably, don't use lightning often yet. Either because it's responsibly tough to run your own lightning node, or because just using bitcoin without custodians is already too confident for the average Joe to make him get involved further.

They need to understand they can't have that unconfirmed option forever though. To increase that 15% they could provide greater rewards for purchases with lightning.

---

---

Edit:

It's reasonable to assume that such attacker is a miner.

If my old man memory is correct they used to give you a bit more. Not a lot more but a bit. Could have been fold, really not sure but I do remember getting a better discount someplace when using lightning for giftcards.

What they COULD do is keep smaller lightning channels open to them. I have opened a few and they auto close them after a while even while being balanced with a decent amount. Don't know why, and finally gave up caring sometime over the summer. Just stopped trying.

Back OT, did spend some time reading since my last post. I still think we should wait, but I do see the other sides view a bit more.
<shrug>
Beating a dead horse, it's going to happen.....

-Dave

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.

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.

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.

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. (https://github.com/bitcoin/bitcoin/releases/tag/v24.0) Will be an interesting few months to see how the mempool behaves.

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.

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 :D )

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

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

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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 (https://github.com/lightningd/plugins/tree/master/autopilot).

It should also be very easy to set up using Umbrel (https://github.com/getumbrel/umbrel-core-lightning) for instance.

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

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

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 (https://github.com/bitcoin/bitcoin/releases/tag/v24.0), and it is available on bitcoincore.org (https://bitcoincore.org/bin/bitcoin-core-24.0/). There are already 230 nodes running it according to blockchair (https://blockchair.com/bitcoin/nodes). 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.

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.

Docker is almost 10 years old (https://en.wikipedia.org/wiki/Docker_(software)). 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.

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.

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.

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.

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.

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

It's not new in the timescale of technology. ;D 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 (https://bitcointalk.org/index.php?topic=5366854.0))

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 (https://runcitadel.space/) 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 (https://bitcointalk.org/index.php?topic=5356129.0)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.


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.

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.

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.

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.

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.

Came across this site via the mailing list: https://fullrbf.mempool.observer. It's been set up by 0xB10C (https://b10c.me/). 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.

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

The incentive structure is what made Bitcoin actually is today, although some altruism was required to boot-strap the network.

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.

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.

After reading a great recap on the matter (https://github.com/glozow/bitcoin-notes/blob/full-rbf/full-rbf.md), 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.

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.

Great! getmempoolinfo works, thanks!

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/

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?

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

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

Do you mean those puzzles (https://bitcointalk.org/index.php?topic=1306983.0)? All the easy ones are long gone, and for the difficult ones it's not so likely different people will find the keys at the same time.

Interesting approach, I hadn't thought of this. How long would it take to solve the puzzle with known pubkey?

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:

If only you would have read what this topic is about.

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.

We are specifically talking about full RBF, not opt-in RBF.

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?

Yes.

You could try actually reading this thread. It is already implemented, but only a minority of miners have currently enabled it.

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.

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.

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

If my transaction doesn't signals for RBF but nodes automatically convert it into RBF enabled transaction, how will I be able to use the RBF option? I mean, let's say that my wallet doesn't support RBF but as I understood, nodes mark all of them as RBF enabled. If my wallet doesn't support RBF, there will be no option for me in software to increase the transaction fee. What's the point there? Or did I misunderstood it?

From my personal experience, every service that accepts transactions with 0 confirmation expects from you to pay high fee, enough to get confirmed in few upcoming blocks. If the fee was not enough, I always had to wait at least for one confirmation. Or in case of casinos, I was able to play with deposited amount despite the fact that it had 0 confirmation but I was unable to withdraw them at least till 1, 3 or 6 confirmation.
So, I think that won't be a huge problem if companies aren't able to accept zero confirmation transactions. At least when I have used that option, that was always formal, I don't really know if your experience is different. You have probably used more bitcoin services than me.

That sounds very logical! But kinda confusing for the nodes, wonder if it causes some kind of danger on network, something similar to double-spending.

The point there is to use a better wallet. :P Network rules are not bound or limited by third party developers failing to implement basic functions in their software. Being able to replace an unconfirmed transaction is an increasingly basic function of bitcoin. If your wallet does not allow you to do that, then find a better wallet which does.

The only danger is if you accept zero confirmation transactions. However, these have never really been safe to accept in the first place, but some businesses accepted that risk for the convenience they brought. Full RBF makes no difference to confirmed transactions.

If my wallet allows RBF and still it depends on me to use that option, then what's the point of full RBF over opt-in RBF?
Let's imagine we already have full RBF:
I download wallet X, it doesn't support RBF, so despite the fact that my transaction is marked as RBF enabled, I'm unable to use that option because of my bad wallet.
I download electrum, enable RBF and sign a RBF enabled transaction, I could use RBF yesterday and I can use it today, doesn't matter whether it's an opt-in option or not. If I want to use it, I can use it. It can probably benefit people who use Electrum but forgot to enable RBF but how common is that?

On an individual level for simple transactions, then no, there is no difference for you between opt in or full RBF.

The main reasons for full RBF are explained in one of the mailing list posts I linked in the OP: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html

In short, full RBF eliminates a number of DoS attacks against multi-party transactions such as Lightning channels and coinjoins, therefore allowing further development of these technologies.

which wallet you recommend that support RBF, i want to send a transaction and make it final with RBF disabled
how to do this?
even if the node is full RBF is this possible

in other word how to make a transaction final without any possibility to double spend it

Unfortunately, that user is no longer with us. You can stick with any reputable wallet nowadays, and it supports double-spending with RBF.

That is not possible, and it never was in the first place. When your transaction has 0 confirmations, it is by the protocol not final. If you're referring to the mempool policy rule before full RBF, then it is neither possible. Almost all nodes will have upgraded to Full RBF by now, and even if full RBF nodes are a tiny minority, it's enough to reach the mempool of the mining pools.

thank you for answering

is it possible to have a transaction confirmed in few sec
by putting the higher fee on the time

by saying final i meant with no possibility to rteplace it with another one

The fastest that you can have it confirmed is in the next block, which can happen anytime. From the next second now to even two hours after. You will have to select the highest fee, though, which as we speak is 43 sat/vb (and use RBF in case that's become less than the highest).

Only if it's confirmed. If it's 0-conf, it can be double-spent with another 0-conf.

These are some wallets that support opt-in RBF: Bitcoin open source wallets that support replace-by-fee (RBF) (https://bitcointalk.org/index.php?topic=5422456.0)

If you are not a full node runner, I will advice you to use any of the wallets on the above link.

I have used Electrum, Sparrow and Bluewallet. They are reputed and open source.

If you are a full node runner, you can enable full RBF. Although, SPV wallets that look for nodes that support it should be able to double spend unconfirmed transaction with high fee also even if the transaction does not support opt-in RBF.

What BlackHatCoiner meant is that a transaction that is not confirmed can be double spent.

A transaction can be confirmed within some seconds and it may take some minutes. It depends on the time you make the transaction, the fee rate that you used and the time the next block is mined.

As mentioned by BlackHatCoiner above, if the fee you pay for your transaction is high enough, it will be confirmed in the next block and I just want to add that blocks are mined at the rate of 1 per ~ 10 minutes on average.

its very clear answer i get it

i see https://mempool.space/
next block found in 13min sometimes 19min and some times in 2min the next block mined
 ???

higher fee +56 sat/vB


sometimes things confused me like in here block time is ~10min right?

It's "average" block time and not an absolute value.

That is based from the adjusted "difficulty" from the previous 2016 blocks (about 2 weeks).
The harder the difficulty, the harder it is to produce a hash lower than the "target".
So since mining is basically generation of pseudo-random hash, we will never know if miners get lucky enough to generate a valid hash in the next second or unlucky to generate it after an hour.

Is there any particular reason for this?
Because in normal circumstances, this shouldn't be an issue if you're the sole owner of the private key.
Solved puzzle 66 or something?

its about this topic bitcoin puzzle
i saw people talk about things didn't know or hear about beore
like this double spend and RBF
https://bitcointalk.org/index.php?topic=1306983.0;topicseen

Okay, as I thought.

There are actually a few topics here that already addresses that concern and the consensus is:
"it's not currently possible without the help of a trusted cooperating mining pool/solo miner".

Here's to point you to one of the threads: solve key 66 67 Puzzle how to avoid double spends the tx? (https://bitcointalk.org/index.php?topic=5492493.0)
AFAIK, there are other discussions that aren't in the first page or posted as a reply to other topics.

What would be the odds of a mining pool trying to replace the mined block and take the puzzle money for themselves? Normally, it's not worth the risk. But if the puzzle prize is (much) large compared to the block reward, that balance may change.

The smallest puzzle on address 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so has at the moment of writing 6.60056114 BTC. The basic block reward without fees is now 3.125 BTC. Which means, that if a block has no fees, then the easiest puzzle is worth more than the newly created coins from two blocks.

The blockchain is publicly available, so if ever, that mining pool is risking their reputation for a couple more bitcoins.
vjudeu's reply to the linked topic in my previous post has a nice take on that matter: /index.php?topic=5492493.msg63955089#msg63955089 (https://bitcointalk.org/index.php?topic=5492493.msg63955089#msg63955089)

If that's a big mining pool that has a slight chance to do that, the odds that they'll do that is still low.
If a small solo miner who got no reputation to lose, they will need a tremendous luck to pull that off.

Foundry USA currently has access to approximately 28% of the hashrate. This means that it has 39% probability to successfully rewrite the entire previous block and mine another one on a row. Therefore, they have two choices.

• Either continue honestly, with 28% chance of mining the next block and earning 3.125 BTC, or
• Gamble the hashpower of 2 blocks, with 39% chance of success, earning about 10 BTC.

Theoretically, it's worth the gamble, even though I haven't worked on the exact math behind it. However, in practice, destroying reputation like that is a suicide.

It is possible to publicly announce SHA-256 of the public key, and get it deeply confirmed, and announced everywhere. Then, if any mining pool will try to overwrite a valid block, there will be a strong, publicly-verifiable evidence, that they did it.

Because the solver can announce for example "OP_RIPEMD160 62e907b15cbf27d5425399ebf6f0fb50ebb88f18 OP_EQUALVERIFY <solverPubKey> OP_CHECKSIG", and get it deeply confirmed, without trusting anyone, and without touching the puzzle. And then, everyone can see, if the reward from the puzzle was first moved into "solverPubKey" or not.

Somehow this probability is always larger than I'd expect intuitively. Your answer seems to be correct:
https://learnmeabitcoin.com/diagrams/png/blockchain-51-attack-mining-power-success-chart.png

Being the first to solve the puzzle is meaningless if someone else beats you to getting their transaction confirmed. Someone else could have solved the puzzle between the time you took to create this transaction, and broadcast the real one.

Remember that if Foundry turned evil, it'd "migrate" its hashrate elsewhere. Therefore, the network would have less hashrate without noticing.

It become even larger if you skip the "mine another block on a row". Foundry has 58% chance to re-write an alternative chain by simply re-writing the most recently mined block (1-conf). However, most of the nodes will have already accepted another chain, and probably most pools will be mining on that other chain. Therefore, they won't accomplish anything by rewriting the previous block. They need to rewrite the previous and mine one on top, so that everyone accepts this chain.  

And then what. Would other pools just stand there and take it or would they put a filter in that looks for foundry in the Coinbase tag and invalidate those blocks.
AntPool and Via and F2 would crush Foundry out of existence if they really tried that.
People would be screaming on both sides about it, but if any pool ever tried it would not last long.

-Dave

I'm not sure yet on which side I'd be screaming. On the one hand, replacing a valid block for profit is bad, but on the other hand, ignoring the longest chain to keep mining a shorter chain is also bad. I'm not sure yet which is the worst.

Practically speaking, they wouldn't have done this beforehand, so when Foundry mines two blocks on a row and creates a longer chain, their full node software would automatically switch to that. At least, I'm not aware of a mining pool which has altered their node software for that particular case; makes no sense.

Followed by their reputation. No sane miner would mine on a pool that wants to crush other mining pools out of revenge.

Ignoring the longest chain for the sake of ethics is one of the most destructive ideas. Bitcoin is based in a game theory, and it shall be based in this forever.