A few months ago Bitcoin core 24.0 was released and this release came with a lot of controversy. In fact even today, there is pressure to roll back the changes made in this release .
So what was the issue?
The core feature of the release was a change affecting some big industry players, the network's scalability and security.
I'm talking about the mempoolfullrbf configuration option.
Here’s a simple breakdown.
Mempoolfullrbf refers to:
The Bitcoin Memory pool which is the 'waiting room' for all unconfirmed transactions on the Bitcoin network.
And RBF stands for Replace-by-Fee a mempool policy that allows nodes to decide between conflicting unconfirmed transactions based on feerate.
Prior to RBF, the mempool accepted whichever transaction it saw first.
In 2016 with the introduction of BIP 125 Bitcoin Core has used what's referred to opt-in - RBF. Where transactions in the mempool can be replaced IF they signaled they were replaceable i.e. they opted in.
This release introduces Full-RBF which allows full replacement of any transaction as distinct from only replacing transactions that opt-in to it.
Why is this controversial?
There are industry players using zero-confirmation transactions in their applications. To put it another way - they're accepting payments which are sitting in the mempool.
This is something which everyone knows is theoretically dangerous but hasn't been an issue because once the bitcoin network has fully propagated a non-replace-by-fee transaction, you need the collaboration of a miner to replace it, which isn't easy to get today.
Even though many of the biggest miners offer off-band transaction broadcasting services, they currently won't process conflicting transactions (double spends)
With the introduction of Full RBF these zero confirmation transactions are simply too risky. The chances of facing a double spend have gone up significantly *IF* you're someone who's accepting 0-conf transactions.
So why did protocol developers push forward with this change?
The point of Bitcoin blocks and proof of work is to solve double-spending.
When a miner receives two conflicting transactions the highest security policy is to have them take the higher fee. An assumption that miners are rational is better than assuming miners are nice.
Unfortunately while scaling Bitcoin through zero-confirmation transactions looks tempting. The reality is it's not possible to do so without damaging security and that's why we have the lightning network.
thomas_fahrer / Tom
npub1xq…pd8s7
2023-02-21 11:36:01
Author Public Key
npub1xqp7ktjtav34zhdvqzdxhm3gvmkak6q9vr60ukvrshxe8xj67wlsvpd8s7Published at
2023-02-21 11:36:01Event JSON
{
"id": "9e558e26435b5fc85d268ca5c831775e90da052a4123974e172ef9edada9d077",
"pubkey": "3003eb2e4beb23515dac009a6bee2866eddb680560f4fe598385cd939a5af3bf",
"created_at": 1676975761,
"kind": 1,
"tags": [],
"content": "A few months ago Bitcoin core 24.0 was released and this release came with a lot of controversy. In fact even today, there is pressure to roll back the changes made in this release .\n\n So what was the issue?\n\nThe core feature of the release was a change affecting some big industry players, the network's scalability and security.\n\nI'm talking about the mempoolfullrbf configuration option. \n\nHere’s a simple breakdown.\n\nMempoolfullrbf refers to:\n\nThe Bitcoin Memory pool which is the 'waiting room' for all unconfirmed transactions on the Bitcoin network.\n\nAnd RBF stands for Replace-by-Fee a mempool policy that allows nodes to decide between conflicting unconfirmed transactions based on feerate.\n\nPrior to RBF, the mempool accepted whichever transaction it saw first.\n\nIn 2016 with the introduction of BIP 125 Bitcoin Core has used what's referred to opt-in - RBF. Where transactions in the mempool can be replaced IF they signaled they were replaceable i.e. they opted in.\n\nThis release introduces Full-RBF which allows full replacement of any transaction as distinct from only replacing transactions that opt-in to it.\n\nWhy is this controversial?\n\nThere are industry players using zero-confirmation transactions in their applications. To put it another way - they're accepting payments which are sitting in the mempool.\n\nThis is something which everyone knows is theoretically dangerous but hasn't been an issue because once the bitcoin network has fully propagated a non-replace-by-fee transaction, you need the collaboration of a miner to replace it, which isn't easy to get today. \n\nEven though many of the biggest miners offer off-band transaction broadcasting services, they currently won't process conflicting transactions (double spends)\nWith the introduction of Full RBF these zero confirmation transactions are simply too risky. The chances of facing a double spend have gone up significantly *IF* you're someone who's accepting 0-conf transactions. \n\nSo why did protocol developers push forward with this change?\n\nThe point of Bitcoin blocks and proof of work is to solve double-spending. \nWhen a miner receives two conflicting transactions the highest security policy is to have them take the higher fee. An assumption that miners are rational is better than assuming miners are nice.\n\nUnfortunately while scaling Bitcoin through zero-confirmation transactions looks tempting. The reality is it's not possible to do so without damaging security and that's why we have the lightning network.\n",
"sig": "19cd733b52985332572bf71072c4a6d90e550faa883a03a98c5404bf39e56b35eb5f4b9fd8ac445e7f5ca16d358ec058865af6f6998e403aa4a07fb5ab4ae953"
}