search

bitcoin-cap / bcap

Repo for Analyzing Bitcoin Consensus: Risks in Protocol Upgrades
Creative Commons Zero v1.0 Universal
121 stars 13 forks source link

Soft Fork Risks underrepresented #29

Open BitcoinErrorLog opened 2 weeks ago

BitcoinErrorLog commented 2 weeks ago

BCAP details the difference between soft and hard forks and highlights risks around contentious upgrades. It gives practical examples like SegWit and Bitcoin Cash but portrays soft forks as inherently better due to backward compatibility.

In practice, many soft forks can effectively be hard, and due to shallow support for old versions, most Bitcoin Core users are forced to accept all updates eventually. These aspects should be acknowledged.

Soft forks can covertly tighten rules, reducing optionality without explicit user consent. This hidden cost—complexity and decreased fungibility—gets overlooked in BCAP’s analysis.

Soft forks have economic and moral implications beyond technical compatibility. The BCAP analysis misses how these changes can silently impact user incentives and the network’s overall health.

Giszmo commented 2 weeks ago

Also "Furthermore, for soft forks, only the nodes that want to use the newly proposed rules have to upgrade." is wrong as clearly miners have to upgrade, too. If they don't, they risk being in violation with tighter rules and getting rejected by upgraded miners.

moneyball commented 2 weeks ago

BCAP doesn't intend to be biased toward soft forks. In fact, a huge portion of the project right now analyzes an enormous risk with the soft fork approach with a bounty claim possibility if there isn't strong enforcement of an activation by Economic Nodes.

If someone opens a PR to provide as fair as possible comparison between hard and soft forks, that sounds like a good improvement to me. Table 1 here compares them https://bitcoincore.academy/consensus-changes.html

Leo: Agree miners must upgrade. This is described elsewhere and nodes in that sentence intended to imply (non-miner) nodes, but I agree we can change the wording to make that clear.

On Thu, Nov 7, 2024 at 3:13 PM Leo Wandersleb @.***> wrote:

Also "Furthermore, for soft forks, only the nodes that want to use the newly proposed rules have to upgrade." is wrong as clearly miners have to upgrade, too. If they don't, they risk being in violation with tighter rules and getting rejected by upgraded miners.

— Reply to this email directly, view it on GitHub https://github.com/bitcoin-cap/bcap/issues/29#issuecomment-2463406583, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPUA4LPTP65J7XFHBZP43Z7PXYHAVCNFSM6AAAAABRMIPBVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTGQYDMNJYGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

BitcoinErrorLog commented 1 week ago

Not sure if he wants to get involved, by I will at least tag @evoskuil

evoskuil commented 1 week ago

I haven’t read it, but soft forks are not backward compatible rules.

Majority hash power enforcement is required to prevent a chain split that will otherwise result from soft fork deployment by economic nodes. No fraction of economic node support can prevent such a split between it and other nodes.

As for terminology I personally avoid the term “upgrade” to refer to rule additions. A new rule is a new coin, and what may be an upgrade to some may look like a downgrade or even an attack to others. For example, state censorship can be imposed through a soft fork (i.e. majority hash power enforcement). The question is only whether the new coin will coexist with the preceding coin (chain split), or will the new coin or preceding coin cease to exist.

moneyball commented 5 days ago

I agree the language "upgrade" implies improvement and that may or may not be the case. @rencryptofish there are dozens of instances of "upgrade" in BCAP right now including the title. I think we should evaluate what it would look like to choose more neutral language.

Also @Giszmo's comment about about miners is something we could improve the wording as well.