MSTR Cat

Blockchain/Level V · Layers/5.2 Other layers/Lesson 1

What bitcoin lacks, and who you trust to add it

The ledger that removed the administrator, and the trust model of every layer above it

MaterialsA block explorer with transaction graph visualizationThe Bitcoin white paper (2008)BIP-341 documentation for TaprootA spreadsheet with columns: Protocol, Custodian, Exit Trigger, Collusion Risk

Wonder

  1. Why does Bitcoin have no equivalent of a token ‘approval’?
  2. What is lost when a scripting language becomes expressive enough to compile any program?
  3. How can a market exist without a central party holding the keys or setting the rules?

Explore

    Part IWhat Bitcoin already removes, and what it lacks

  1. Bitcoin removes the administrator. There are no admin keys, no token approvals, and no upgradeable contracts. Issuance is capped at 21 million coins, predictable by schedule, with subsidy halving every 210,000 blocks. Rules change only through broad consensus among thousands of independent nodes. This design eliminates a class of attacks found in other systems: if there is no key to steal and no contract to upgrade, there is nothing for an administrator to exploit or for a company to seize.
  2. The UTXO model makes every spend explicit. A transaction consumes specific previous outputs and creates new ones. There are no account balances that a contract can debit later. This structure prevents ‘drainer’ approvals, where a user signs a broad permission allowing another party to move unlimited funds later. With the default signature type (SIGHASH_ALL), a signature commits to these exact inputs and outputs; other signature modes can leave outputs open, and scams have exploited them. If the user does not sign the next transaction, nothing moves.
  3. What Bitcoin lacks is expressiveness and speed. Script is deliberately limited; it cannot perform arbitrary computation or loop indefinitely. Blocks arrive roughly every ten minutes, meaning settlement is slow compared to chains that produce blocks in seconds. There is no native support for tokens or markets within the base layer protocol. These constraints are intentional trade-offs: limiting what the script can do prevents bugs from becoming consensus-breaking exploits, and slower blocks allow for robust validation by a decentralized network of full nodes.
  4. The design question is how to add markets without reintroducing the weaknesses Bitcoin avoided. Adding a complex scripting language invites smart contract vulnerabilities. Adding fast blocks often requires centralization or permissioned validators to maintain finality. Introducing native tokens can create new attack surfaces for inflation or manipulation. Any extension must preserve the property that no single entity controls the issuance or rules of the asset, even if it means accepting slower settlement or higher fees.
  5. Layer 2 solutions and metaprotocols attempt to bridge this gap. They add functionality like fast payments or token issuance while anchoring security to Bitcoin’s consensus. However, these layers introduce new trust models: some rely on federations of signers, others on optimistic verification games where at least one honest operator must challenge fraud. Each approach trades off different aspects of decentralization and speed. The goal is not to make Bitcoin into a general-purpose computer, but to extend its utility without compromising the core security model that made it resilient.
  6. Open a block explorer and look up any recent transaction. Examine the inputs and outputs. Note how each input references a specific previous output by its transaction ID and index. Now compare this to an account-based chain where balances are just numbers in a global state. The difference is structural: Bitcoin’s model forces every movement of value to be explicit, auditable, and tied to a specific signature, leaving no room for hidden administrative overrides or broad permissions.

    7. Part IIBitcoin layer 2s and their trust models

  7. Lightning Network channels extend Bitcoin’s payment capability without moving coins to a custodian. The white paper by Joseph Poon and Thaddeus Dryja was first drafted in 2015 and published in final form in 2016; mainnet use followed in 2018. Each channel locks funds into a two-party state; if one party cheats, the other broadcasts a penalty transaction to Bitcoin. This model is trust-minimized because no third party holds the keys, but it remains point-to-point. It solves payment finality, not shared liquidity or market making.
  8. Liquid, launched by Blockstream in 2018, operates as a federated sidechain. A fixed group of ‘functionaries’ signs blocks and manages the peg between Liquid assets and base-layer Bitcoin. Blocks come every minute and settle finally in about two, and assets can be issued natively. The trade-off is explicit: users must trust that a supermajority of functionaries (the peg uses an 11-of-15 multisignature) will not collude to steal deposits or halt redemptions. It is fast, but it reintroduces a trusted group.
  9. Stacks runs its own chain, anchored to Bitcoin by committing hashes of its blocks in Bitcoin transactions (Proof of Transfer). Its sBTC peg, open for deposits from December 2024 and withdrawals from April 2025, issues tokens backed by locked native bitcoin managed by a set of signers. This approach allows for expressive smart contracts on Stacks (in Clarity, a deliberately decidable language) while a signer set, a threshold of whom must approve withdrawals, holds the bitcoin. Users trade execution flexibility for reliance on the signer set’s integrity and the bridge’s operational continuity.
  10. BitVM represents a different architectural choice, aiming to bring general computation to Bitcoin without soft forks. Robin Linus’s 2023 proposal used optimistic verification between two parties; BitVM2 (2024) lets anyone challenge. Projects like Citrea, live since January 2026, build on this model, in which one honest participant out of many can stop fraud. This ‘1-of-n honesty’ model shifts trust from a majority consensus to the presence of a single vigilant challenger, but operators must lock or front capital, and withdrawals wait out challenge windows.
  11. Comparing these models reveals distinct risk profiles. Lightning requires no third party but offers limited utility for shared markets. Liquid and Stacks rely on federations or signer sets where collusion is the primary threat. BitVM rollups depend on competitive honesty among operators. The critical variable in every case is custody: who holds the private keys to the underlying bitcoin, and what happens if that entity fails, is hacked, or chooses to defraud.
  12. Exit mechanisms define the true trust model. In Lightning, exit means closing the channel on-chain; if the other party is unresponsive, funds return after a timelock. In Liquid or Stacks, exit requires a redemption request processed by the federation or signers; if they delay or refuse, users are locked in. For BitVM bridges, exit relies on at least one live operator paying the user out; operators’ reimbursement claims then face a challenge period. A user who cannot exit without trusting a third party is not truly self-custodial, regardless of how decentralized the network appears.

Key facts

  • Bitcoin has no admin keys, token approvals, or upgradeable contracts.
  • Issuance is capped at 21 million BTC, with the subsidy halving every 210,000 blocks.
  • The UTXO model makes each spend explicit and prevents broad approval drainers.
  • Script is deliberately limited to prevent arbitrary computation vulnerabilities.
  • Blocks arrive roughly every ten minutes, prioritizing security over speed.
  • Rules change only through broad consensus among independent nodes.
  • Lightning Network channels are trust-minimized but point-to-point, unsuited for shared market liquidity.
  • Liquid (2018) uses a federation of functionaries to sign blocks and manage the bitcoin peg.
  • Stacks sBTC (December 2024) is managed by a set of signers who control the underlying collateral.
  • BitVM rollups like Citrea rely on ‘1-of-n honesty’ where any single honest operator can challenge fraud.
  • Federated sidechains trade decentralization for speed, requiring users to trust that functionaries do not collude.
  • Exit rights determine the effective trust model; if a third party controls redemption, self-custody is compromised.

Exercise nine, six, three, one

9CollectList 9 features or mechanisms found in other blockchain platforms (e.g., Ethereum, Solana). Note what each mechanism allows and who controls it.
6ClusterGroup the 9 into 6 by how Bitcoin handles the same need, if at all.
3DistillReduce the 6 groups to 3 reasons Bitcoin lacks these features.
1CrystallizeWrite 1 sentence on what Bitcoin sacrifices in order to eliminate administrative control over value transfer.

Fact check

Dates, figures and claims checked against the published sources listed below.

Open in the interactive academy →

PT ES ZH JA KO RU DE FR MS