Quote from: NotATether on December 15, 2022, 05:48:15 PM

Wut? FullRBF is disabled by default and you have to go out of your way to manually enable it via a config switch or command line option.

If you don't like the feature, just fork Bitcoin again. There is nothing any of us can do to reverse course. This is the decentralized consensus after all.

As other users have commented, A Fork is not a proper solution for this attack.

Consensus was broken when Core devs decided to go against Bitcoin´s White Paper: For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend.

Each Attack is an opportunity for Bitcoin and bitcoiners to gain self awareness, this is a perfect example as self awareness is the only posible solution. We need better Bitcoin education.

First I'll post my arguments against Full-RBF and then I'll propose a solution:

Full-RBF was deliberately included on Core V24.0 without reaching consensus.

It opens a door to centralization under Blockstream: Bitcoin is not Lightning. Lighting is a L2 solution for scalability of micropayments. Bitcoin L1 is the settlement layer.

Full-RBF solves NO problem: RBF already existed, there was no reason for Full-RBF to be deployed.

Full-RBF enables ANY transaction to be double spendable, any honest transaction could be replaced by a malicious higher fee one. This could result in censorship, seizure of funds by an state actor or theft.
For understanding this last argument I´ll explain one of Bitcoins limitations which should be publicly known if we believe in self custody:

Because of how Bitcoin's cryptography works, You'll not find substantial attack worthy unspent UTXO. This is because whales know that any pvt key gets easier to extract through brute force if you already use it to sing a transaction.
Any system has its limitations and Bitcoin is not the exception. However Bitcoin has been doing great so far with its own.

Any transaction awaiting in the mempool is vulnerable due to this same reason. This is why the first seen rule was included on Bitcoin's white paper.

If a state agent is able to extract a PVT key from a transacción on the mempool in less than 10 minutes on 2022, or in X years from now is not an argument. Full-RBF is opening the back door towards censorship and seizure of Bitcoin's transactions.

Now I'll share with you my suggested solution for this attack. It's a multi layer solution and strong community support is required. But bitcoiners are strong, and Bitcoin will came out stronger than ever:

Social Layer:

Any Bitcoiner that cares for Bitcoin to remain being Bitcoin, and to continue its path towards the wolrd's store of value, must share their disagreement with Core's breach of consensus. I suggest the hashtag #NoFullRBF on every Bitcoin related publication.

A strong educational campaign and continuing program on UTXOs, PVT and Public key's limitations and inner mechanics. Bests practices for self custody, unexpended transactions vulnerabilities, etc.

A campaign for the quick removal of all links to the V24.0 and V24.0.1 from this and all other sites.

Core Dev Layer:

Core must work in a No Full-RBF V25 client to be released as soon as posible.
Any Dev incapable of summarizing, or being concise on their argumentation for Full-RBF must be ignored. As a common attack tactic on social layers is writing long speeches with unintelligible language for others to feel dumb. Don't you fall for this tactic. Also personal attacks must be contained from these discussions. I'll take part if Core Invites me.

They must remove all links to their malicious code as soon as possible.

Full-RBF Nodes Monitor Team

We need a new Dev team in charge of creating the tools for Bitcoin's community to be able to follow the number of nodes running Full-RBF in real time. A team Operational for the rest of Bitcoin's History. (Thanks Peter Todd) As the number of Full-RBF Attacker Nodes must never go over 10%

Protocol Layer

In case we are unable to contain attacker nodes under 10% we will need to adapt the Timechain. I propose a 5 minute block time with all the necessary adjustments for the monetary policy to remain unchanged. This has profound ramifications in terms of orphan Blocks because of networks latency and reaction times which need to be studied further. This is an scenario I prefer to avoid.

#NoFullRBF

Do not download Bitcoin Core V24

If your are running V24 Uninstall immediately!

Security must not be compromised in favor of UX, Scalability, or any other reason unrelated to Bitcoin's value itself.

S_Speche

Posts

Merits