A Bitcoin scaling design

LayerTree

LayerTree lets many people share one Bitcoin output. Who owns what is recorded off-chain in a tree: each member's balance is a leaf, and every node above the leaves holds a hash of its two children and the sum of their amounts, up to a single root. The shared output commits to that root. Each spend of the output must satisfy a covenant, a script that checks a proof against the committed root, applies one rule, and requires the transaction to recreate the output under the new root. So any member can leave in one transaction, at any time, with no timelock, no transactions signed in advance and no expiry date. The operator who runs the tree cannot take anyone's money or stop anyone leaving, and members can join or be removed in bulk for a small cost each.

The life of a tree

The figure follows one tree through seven steps. The tree has eight slots, the boxes along the bottom, and the amounts are small numbers chosen for reading. The strip at the bottom shows what is on the blockchain after each step. Use Next and Prev, or focus the figure and press the arrow keys.

The parts

Each page below takes one piece of the design, steps through it on the same kind of tree, and links to the sections of the specification that define it. Start with the state machine: every other page is an instance of it.

• C-01SPEC 7.1 The state machine The chain stores only a root. Every spend proves the old state, applies a rule, and commits to the new root.
• C-02SPEC 7.3 Joining One member or a whole cohort grafted into empty slots, who pays for it, and what a joiner checks before paying.
• C-03SPEC 7.2 Exiting The proof, the fold, the new root and the payout, and why exiting in pairs saves only part of the cost.
• C-04SPEC 7.5 Paying each other Vouchers, splits, channel leaves and a credit leaf for receiving over Lightning.
• C-05SPEC 7.5.1 Swaps A hash-locked voucher and an HTLC that share one secret, and the order in which they must settle.
• C-06SPEC 7.7 Eviction Leases, removing one expired leaf, and sweeping a whole cohort for a falling cost per leaf.
• C-07SPEC 7.9 Batching Rewriting a cohort in one transaction, detaching it into its own output, and the cost no batch removes.
• C-08SPEC 4.3 Opcode tiers The same transitions built four times, against four sets of proposed opcodes, with what each needs and costs.
• C-09SPEC 11 Scaling and comparison Exit size and transactions to leave from 16 members to four billion, against transaction trees, Lightning and bare outputs, and where LayerTree loses.
• C-10SPEC 10.2 Formal verification What the Lean model proves about the rules, what it assumes, what the proofs changed, and the planned P model of the off-chain protocol.

What it costs

Bitcoin charges fees by transaction size, measured in virtual bytes (vB). A spend of an ordinary single-owner output with one input and one output is about 111 vB. The figures below are for a tree of depth 16, which has 65,536 slots.

• Leaving alone costs about 1,020 vB, roughly nine times a bare spend. The price is the proof, and it does not grow with the number of members. Leaving a tree of transactions of the same size, as in Ark-style designs, costs about 2,511 vB. With one purpose-built Merkle-sum opcode, which the repository specifies and measures but nobody has proposed yet, the exit is about 540 vB at this size and grows by 10 vB per doubling of members; the scaling page follows it to four billion.
• Joining in a cohort costs under 1 vB per member once the cohort has about a thousand members, when the operator funds the graft and members pay for their balances off-chain.
• Sweeping an expired cohort costs about 158 vB per leaf for 51 leaves.
• Moving value between members costs nothing on-chain, because it happens in channels inside leaves or by signed vouchers.

The design moves the cost of sharing out of everyday use and into the exit. A member who never leaves alone pays almost nothing; a member who does pays for the proof.

What it does not promise

Nobody has to let you in.

Joining needs the operator's signature. A person who is never admitted has lost nothing, but nothing guarantees admission.

A grafted subtree can be empty of meaning.

When the operator grafts a cohort, the covenant sees only the subtree's hash and its claimed sum. If no real tree stands behind that hash, nobody can ever prove a leaf under it, and the value is frozen. The sums still balance, so no value is created, and existing members are unaffected. The protection is a rule for joiners: check your own path inside the subtree before you fund it.

Everything passes through one output.

Every transition spends and recreates the same output, so unconfirmed transitions form a chain. Bitcoin's default relay policy allows about 25 unconfirmed descendants, which caps how fast strangers can leave one at a time. A batch counts once against that cap. One cheap transaction early in the chain can also hold back the fee rate of everything behind it. Splitting a deployment into several trees is the structural answer, with each tree sized by how fast its members may need to leave.

Cheap eviction is also cheap griefing.

At about 160 vB per leaf, the operator can clear expired members cheaply. Members who want a firm guarantee choose a lease far in the future, or no lease at all.

None of it runs on Bitcoin today.

The scripts use opcodes that have been proposed but not activated. The tiers page lists which ones.

Where the numbers come from

Every script and witness size on this site is measured, not estimated; whole-transaction sizes follow the specification's fee model, which runs about 1% under the serialised transaction (1,020 against 1,030 vB for the depth-16 exit). The repository's tapscript simulator executes each reference script and records its size in spec/scripts/sizes.md. Section 11 of the specification turns those sizes into whole transactions by adding a fee input, a change output and the transaction's fixed overhead, and spec/fee-analysis.md converts them into fees. Comparisons with bare outputs, Lightning and Ark come from design/cost-comparison.md, and the batching, grafting and receiving figures from the design pages linked at the foot of each component page. Unless a page says otherwise, figures are for the FULL tier, the dense tree profile and depth 16. The amounts inside the animations are illustrative, and the short root hashes they show are labels that change when the tree changes, not real hashes.

Words used on this site

Leaf

One member's record in the tree: an amount, the keys that may spend it, a lease height and a counter.

Root

The single hash at the top of the tree. Each node's hash covers its two children's hashes and sums, so the root changes when any leaf changes.

Proof

A leaf together with the sibling node at each level between it and the root. Hashing up from the leaf with those siblings must reproduce the root.

Fold

Hashing up a path to compute a root, once with the old node to check the proof and once with the new node to get the next root.

Covenant

A script that restricts the transaction allowed to spend an output, here by requiring it to recreate the tree output under a correctly computed new root.

Operator

The party that runs the tree. It admits members, can remove members whose lease has run out, and co-signs some changes. It holds no key over anyone's balance.

Cohort

A group of members grafted together into one aligned subtree, usually sharing a lease.

Lease

A block height written into a leaf. After it, the operator may evict the leaf by paying out its full amount.

Voucher

A message signed by a leaf's owner that lets its holder carve a new leaf out of the owner's balance later, without the owner.

For the explanation in prose, read CONCEPTS.md; for the normative rules, spec/layertree.md.

The paper

The paper comes in two versions built from the same sources. The short version (PDF) is the conference-length paper: the construction, the tiers, the evaluation and the Lightning composition in fifteen pages, with the per-operation detail in appendices. The full version (PDF) adds the ideal functionality and the UC simulation argument, every predicate and algorithm in full, the Lean correspondence and the complete script listings.