Nostr Web Client

Bitcoin Core developers cannot change the rules of Bitcoin "from above" because the protocol works by consensus. A change only becomes effective if more than 90% of the network (nodes and miners) adopt it. Without this consensus, the new code has no effect on the timechain.

Furthermore, a minority that does not agree with an update can perform a hard fork and continue with their own timechain. This is precisely what we are seeing today in the debate over OP_RETURN and related proposals:

the network decides, not the developers.

Des Imoto マキシ 1mo ago 💬 1

In theory…but in reality I see this:

….turns out, the nodes are very passive, complacent, naive and also susceptible to a Sybil attack. Especially due to the low number. V30 only needs to spawn up couple of tausend nodes.

IMHO, it’s also not about the severity of the change, it’s that the development process is the preferred perimeter to attack (and I’m repeating someone else’s thoughts here):

- Cheaper than legislation: Defaults and "safety" framing do the enforcement work.

- Plausible deniability: "We're just improving performance".

- Asymmetric impact: hits sovereign users hardest; institutional wrappers unaffected.

Development-Process Capture = Perimeter Control

You don't have to "hack" Bitcoin's consensus rules to influence how the network behaves.

You can steer what gets relayed, mined, or socially accepted by quietly shaping the development process — who gets funded, who reviews changes, which features become defaults, how releases are timed, and how communication is framed.

If you expect for governments to come out and try to ban Bitcoin, don't because that's not how the system works.

Systems don't rely on bans; they use knobs — adjustable defaults, standards, and processes that subtly guide behavior.

The Bitcoin development process is a dense cluster of such knobs.

Open source ≠ immune

Control flows through funding, maintainers, policy defaults, and release cadence.

There are probably less than a 100 people in the world who have game theory studied:

- the development process control surfaces — where steering actually happens

- what capture looks like

- how capture changes outcomes

- why the development process is the preferred perimeter to attack

…it’s the only thing that can kill Bitcoin. So now what? BIP444. Hard fork? Not good for adoption. Not good for THE monetary network of humanity.

Reply to this note

Please Login to reply.

Discussion

Jacopo Graziuso 1mo ago 💬 1

While the development process can certainly influence discussions and guide preferences, it cannot replace the fundamental mechanism of distributed consensus. It is important to distinguish between 'influence' and 'rule change': the former concerns the social sphere of debate, while the latter concerns cryptographic validation performed by nodes.

Even when there are attempts to 'capture' the development process (through funding, code review or default settings), the consensus rules will not change until the economic majority of nodes voluntarily accept the update. Without this validation, the new code does not activate on the Timecoin network.

Therefore, the network remains resilient not because it is immune to external pressures, but because decision-making power is distributed: each full node retains the ability to reject a change and, if necessary, continue on an alternative version of the protocol. This greatly limits the possibility of directing Bitcoin through 'social levers' alone because the final point of verification is not opinion, but compatibility with the rules.

Des Imoto マキシ 1mo ago 💬 1

Sybil attack? There are only ~7,000 active active players. And we do know from Core themselves, they spawned v30 nodes.

Jacopo Graziuso 1mo ago 💬 1

The number of nodes visible in a public scan does not represent the full network of validating nodes. Many nodes operate in 'unreachable' mode and do not appear in the statistics. For example, Bitnodes' research consistently indicates that observable nodes are only a fraction of the total.

Furthermore, a Sybil attack on the 'visible' component does not affect the consensus rules. While a node can adopt any user agent or version, it cannot impose new rules if the economic majority of fully validating nodes rejects the change. Creating thousands of reconfigured nodes does not alter the validation of the fundamental rules because security stems from local consensus verification rather than counting announced nodes.

Similarly, the use of a particular version by multiple instances does not imply that it can unilaterally change the protocol; an update only becomes effective if it is voluntarily accepted by those who validate the chain. The ability to reject incompatible rules prevents an artificial increase in nodes, even if coordinated, from resulting in a change to the rules.

Des Imoto マキシ 1mo ago 💬 1

So where or what is the coordination to reject these changes?

Jacopo Graziuso 1mo ago 💬 1

The network's defining feature is that it does not require centralised coordination to reject incompatible rules. Each fully validating node applies the same consensus rules locally and autonomously discards blocks that do not comply with them. The 'rejection mechanism' is not a collective process, but rather an aggregation of individual, independent decisions.

For this reason, a change only becomes effective when a significant proportion of nodes voluntarily choose to adopt it. If adoption does not occur, the new code has no effect on the timechain, regardless of the number of reconfigured nodes or any attempts at external coordination.

Des Imoto マキシ 1mo ago 💬 1

Agree with that; I’m not talking about how consensus works to decide what block is valid, but the changes to the code, that sets the rules for what gets validated. Ie Core v30. Core v30 is like a virus. It says it’s ok to include data in a block. It increases the attack surface. Maybe the changes will be a slow Degradation. Maybe the Next change could be fatal. And, at a higher level, why even mess with the code? It’s fine now. Having these devs mess with the code is the single biggest threat to Bitcoin. Bitcoin can not be the hardest money in the world if idiots can just mess with the code. Simon summarizes the problem well:

nostr:nevent1qqsf7km04ntfg65sdcpa7zanq9cse0qsfecrrwlp7lnha9ykkgadussq2lqlq

Scurvydog 1mo ago 💬 1

Now you know why it was a scam the whole time. Dont own the code? Don’t buy the coin.

Jacopo Graziuso 1mo ago 💬 2

The distinction between modifying the code and the consensus rules is fundamental. While an implementation may introduce new features, improvements or questionable choices, no change becomes effective on the Timecoin network unless it is voluntarily adopted by its validators. Bitcoin's security does not stem from the code remaining unchanged, but from the fact that consensus is distributed, with each node independently rejecting blocks that are incompatible with the shared rules.

Therefore, the presence of specific software versions – even if widespread – does not constitute control over the protocol. A node may run a version of the code that accepts new features; however, if these features involve blocks or transactions that are incompatible with the existing consensus, the other nodes will discard them. This prevents the change from propagating.

It is legitimate to discuss software governance, the risk of development becoming concentrated, and the need for alternative implementations: competition within the ecosystem is beneficial as it reduces the number of potential failure points. However, these aspects do not enable a group, whether financial, political or technological, to 'alter' Bitcoin from above. The insurmountable limit is local verification of the rules: without widespread adoption by validating nodes, the code cannot change the protocol.

Bitcoin's protection does not depend on blocking developers or assuming hostile coordination, but rather on the network's structural capacity to reject any unshared deviation. This property remains unchanged even in scenarios involving strong social, economic, or political pressure.

Scurvydog 1mo ago 💬 2

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

Des Imoto マキシ 1mo ago

The longest TimeChain is the current one.

Jacopo Graziuso 1mo ago 💬 1

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.

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.

Des Imoto マキシ 1mo ago

Same developers/maintainers, same corruption. So we‘re back to the developers are the risk.