Bitcoin Forum
November 14, 2026, 04:49:35 PM *
News: Latest Bitcoin Core release: 32.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Can a blockchain be finished? On base layers that never upgrade  (Read 7 times)
tingorg (OP)
Newbie
*
Online Online

Activity: 6
Merit: 0


View Profile
Today at 03:34:36 PM
 #1


Disclosure up front: I'm the developer of Ting, a chain built around the idea below, so I'm biased. This isn't an announcement (that thread exists, linked at the bottom), and I'm not asking anyone to buy anything. I want to discuss the idea, and I'd like to hear where it breaks.

Most Bitcoiners treat the 21 million cap as untouchable. Not because the code can't be changed, but because changing it is unthinkable, and that's a big part of why people trust it. I've been thinking about what a chain would look like if its whole rule set were treated that way from day one, not just the supply.

A roadmap needs a driver

Almost every chain is expected to keep changing: quantum resistance, scaling, new cryptography, fee markets, spam policy. Every one of those changes has to be agreed on somehow, whether through core developers, a foundation, token holders or miners signalling. No single group necessarily has full control, but the process itself becomes something users have to trust, and something that can be pressured by companies, governments or a loud part of the community.

Some examples:

  • Bitcoin's block size war ended in a split (BCH, 2017), and this year BIP-110 led to another one.
  • Ethereum rolled back the DAO hack in 2016. In 2025, Sui validators froze about $162M of stolen funds after the Cetus hack. Maybe good for the victims, but it shows what coordinated intervention can do.
  • Quantum: Bitcoin's draft BIP-361 proposes eventually restricting coins that haven't migrated to quantum-safe signatures. Whatever you think of it, that's a decision affecting other people's coins, made through a future consensus change.
  • New cryptography on Ethereum needs a protocol upgrade if it is to become a native operation. The BLS12-381 precompile had to wait for Pectra in 2025.

Why it matters if you build on it

If you build something meant to last decades, the rules underneath can change what you built:

  • EIP-1884 (2019) raised the cost of certain operations and broke contracts that relied on the old gas prices.
  • EIP-3529 (2021) removed gas refunds that GasToken depended on, making it no longer viable.
  • EIP-6780 (2024) changed what SELFDESTRUCT does.

Each had good reasons. But on a chain with a roadmap, "what will this be in ten years?" has no definite answer. It depends partly on decisions and disagreements that haven't happened yet.

I've come to think a base layer with nothing left to decide is close to a requirement for decentralization in the long run. If the rules can't be changed within the chain, there's much less to lobby over at the protocol level.

What a finished base layer could look like

The trick is to keep everything that needs to evolve out of consensus. Ting's consensus does four things: it orders transactions with SHA-256 proof of work, runs programs in a deterministic WebAssembly VM, commits to the resulting state, and counts compute, state access, data and storage growth. That's all: two kinds of transaction, 115 instructions, twelve host functions.

Everything else is a program: accounts, signatures, coins, fees, replay protection. There is no native coin, and the protocol mints nothing and charges no fee. It's basically a global VM, with proof of work keeping its transactions in order.

What that does to the examples above:

  • Quantum: a post-quantum signature scheme can be deployed as a program. People can move to it when they choose. Nobody has to fork the base layer or impose a deadline for moving coins.
  • New cryptography: the same principle. New algorithms can be implemented in programs without waiting for a hard fork.
  • Scaling: the cost of every operation is fixed forever, in logical units, not time. The only thing that moves is block capacity, through a miner vote whose own rules are fixed: two thirds of the work to grow 5% a step, a simple majority to shrink 10%, floors set at genesis, no ceiling. As nodes get faster, miners can vote more capacity in.
  • Upgrades: the version field is always 1. A different rule set is a different chain with a different ChainId, not an upgrade under the same name.


Governance doesn't vanish, it moves up a layer

This doesn't remove governance. It moves much of it to where it's opt-in. A program can have an upgrade key, a council, a vote, whatever its users accept, and someone who doesn't trust that can use a different program.

The base layer still has miners, economic incentives and social consensus. But there is no mechanism for voting in a new set of consensus rules that every application must then live with.

Disagreeing without splitting

This is the part I find most interesting. When programs are flexible and composable, two groups can make opposite choices without necessarily splitting the underlying chain.

In the standard coin program, an account is whatever signature program it names: a single secp256k1 key, a passkey, a multisig, an identity that guardians can recover, or a post-quantum scheme once someone deploys one. The coin doesn't care. So one person can insist on a plain key with no recovery, another can want guardians, and they can still hold and pay each other in the same coin.

On most chains, disagreements over consensus rules can end in a fork, dividing the network. Here, many of those disagreements can instead end in two programs on one chain.

What it costs

I don't think this is free:

  • "Frozen" is a social commitment, not physics. Anyone can fork. The point is that a fork is plainly a new chain, not something presented as an upgrade of the same one. Whether people respect that is the real test.
  • Mistakes are permanent. If a serious flaw shows up, the answer is a new chain with a new genesis that can carry the old state over. That's a hard fork in all but name, and I won't pretend otherwise. The cost moves up front, into specification and testing.
  • A mispriced instruction stays mispriced. The only defences are miners voting capacity down and nodes getting faster.
  • Cryptography written in Wasm is slower than built-in functions, so signature-heavy use gets less throughput.
  • SHA-256 is fixed for good, like in Bitcoin.
  • Miners are paid by coin programs, not by the protocol, so security depends on those coins being worth something. That's untested.

Where Ting actually is

To be clear, Ting isn't there yet. It launched on 21 October 2026 and it has one developer. There are two implementations, one in Rust and one in Go, but I wrote both, so that isn't independence yet. Its hashrate is concentrated too.

A frozen protocol only means something once there are independent implementations, spread-out mining, and a community that would treat any rule change as a new chain.

What it does have is a foundation for that: the rules are in one document, and every node replays a conformance suite stored in the chain's first 325 blocks, so anyone building another implementation can check that it agrees with the existing chain.

There is a coin running on it, Daler, which is one deployment of a standard coin program, with no premine. It's not what this thread is about; the announcement thread covers it.

What I'd like to hear

  • Is ossifying from day one a strength, or does a chain have to be able to adapt to survive?
  • What does a base layer need before it's safe to freeze? What did Ting get wrong?
  • Can a chain without a native coin keep its miners paid in the long run?
  • As a builder or a holder, would you trust a frozen base layer more?

Why freeze, and what it takes: Ting - Why freeze?

Announcement thread: Ting [ANN]
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!