Nostr Web Client

So it depends on the consensus rules only? What if nodes reject different sets of blocks?

Only the longest chain that complies with the consensus rules is recognised. Validity is not defined by length, but by compatibility with the shared rules: a longer but invalid chain is automatically discarded by fully validating nodes.

Developers do not have the power to change the protocol. While they can propose changes to the code, they cannot impose new rules; an update only becomes effective if those who validate the network choose to adopt it. Security derives from the behaviour of independent nodes, not the identity of those who write the software.

If different nodes reject different sets of blocks, the result is a fork in the chain. In that case, the chain with the economic majority of validating nodes prevails. This natural selection mechanism is built into the protocol and is not based on trust in developers, but on local verification of the same rules by users who decide what to validate.

The protocol is designed so that no actor — developer, miner, company or government — can change the rules. Bitcoin's protection stems from the decentralised verification process, rather than the immutability of the code or the reputation of individuals.

Reply to this note

Please Login to reply.

Discussion

Des Imoto マキシ 1mo ago 💬 1

They already have changed the code, Core v30. There are only ~20k nodes. The evil doers can just: spawn new nodes and use influencers to confuse people. The nodes are very passive and complacent. I agree that if we had millions of nodes actively working on securing the system, that would work as intended.

In the meantime we need to educate people and keep it simple. No changes needed to Bitcoin.

Jacopo Graziuso 1mo ago

The code may change, but the rules will not change unless they are voluntarily adopted by the nodes that validate the chain. The addition of thousands of new nodes does not alter this mechanism: if the rules are incompatible, the blocks are discarded. The protocol's resilience comes from this distributed verification, rather than the total number of nodes or the activity of individual developers.