Emerging Technology

Proposals, and where each one stands

Bitcoin changes slowly, and most of what is discussed never becomes a rule. This hub collects the pages that cover the proposals and newer constructions currently under discussion: covenants that would constrain how a coin is spent, drivechains secured by miner signalling, the BitVM construction for verifying computation, and a signature-hash flag aimed at more flexible payment channels. Every page marks its subject as proposed or deployed and states its current status, because that distinction is the first thing a reader needs.

The gap between an idea being published and an idea being adopted is where most of the confusion about Bitcoin's future is generated. A proposal can be discussed for years, implemented in a client, and still never activate, because activation requires a level of agreement that the network does not grant easily. Reading a proposal as though it were a roadmap is the most common mistake in this area, and it is the one these pages are written to avoid.

Each page here does three things. It states what the proposal would change in the protocol. It describes the constructions that change would make possible, and why anyone wants them. And it states the proposal's current status — draft, implemented but unactivated, or deployed — without projecting a timeline. Where the arguments for and against a proposal are genuinely contested, the page presents both rather than taking a side, and it cites the specification or the discussion where the claim can be checked.

Restricting How Coins Move

What if a coin could be constrained in how it is spent?

Bitcoin's spending conditions are deliberately open-ended: a script can require a signature, a timelock, a hash preimage, or a combination, but it cannot easily require that the output be spent in a particular shape. A family of proposals known as covenants would add that ability, and the debate around them is as much about what they would enable as about whether they are safe. This strand sets out the proposals under discussion, the constructions they would make possible, and the arguments on both sides. None of them is deployed, and every page says so.

Start with Covenants

Signature Flexibility

What would more flexible signatures change?

A signature commits to a specific transaction, and the flags that decide exactly what it commits to are part of the protocol. A proposed flag would relax that commitment in a way that makes certain channel constructions — notably eltoo — far simpler to build, at the cost of a new way for a signature to be reused. This strand explains what the proposal changes, why the constructions that depend on it are considered valuable, and where it currently stands in the proposal process. It is a single proposal, and the page treats it as one.

Start with SIGHASH_ANYPREVOUT

Every page in this section

The strands above are the way in. This is the full contents of the section, grouped by whether the page covers a spending constraint or a signature and consensus change.

Spending Constraints

Proposals that would let a script constrain the shape of a future spend, and the sidechain and verification constructions that depend on the idea.

Signature and Consensus Change

A proposed signature-hash flag, the channel construction it would simplify, and the fork mechanics any such change would have to pass through.

SIGHASH_ANYPREVOUTA proposed signature-hash flag aimed at eltoo and more flexible channel constructions.

The reference pages behind the strands

The strands above explain the proposals. These pages hold the underlying record and the methodology, for when you want to check a claim or follow a source.

How a proposal becomes a rule

Every proposal here would have to pass through the same process. These pages carry the mechanics of how Bitcoin's rules have changed before.