LayerTree’s Million-Member Exit Estimate Depends on an Unproposed Opcode

A draft dated Oct. 15 by Lightning Labs developer Olaoluwa Osuntokun models how Bitcoin (BTC) users could share a single transaction output on the Bitcoin network while tracking separate balances off-chain. Its million-member exit figures rely on OP_MERKLESUMUPDATE, an opcode not proposed for Bitcoin, so they are modeled estimates rather than evidence of a live million-member deployment.

The design places each member’s balance in a slot in an off-chain tree, with the shared output committing to that tree. A member could prove a balance and leave through a transaction that updates the shared output. Operators control admission, and members need to check their own tree paths before funding. A malformed graft could leave deposited funds inaccessible.

A depth-16 tree has 65,536 slots. In the FULL tier, a solo exit is estimated at 1,020 virtual bytes (vB), or 1,030 vB when serialized. A different script model estimates exits at 541 vB for 65,536 members and 581 vB for 1,048,576 members. These figures use a different script assumption from the FULL-tier estimate, so they do not measure the same implementation.

A virtual byte measures transaction size, not a fixed fee in dollars or satoshis. The fee depends on the rate paid per vB when the transaction is sent. The million-member figures describe modeled transaction sizes, not a live system processing that many users. A separate comparison uses a 2,511-vB transaction-tree model, which excludes some costs, including fee-boosting transactions.

For a group of about 1,000, the joining estimate is below 1 vB per member if the operator pays for the graft and members fund their balances off-chain. That estimate concerns transaction size; it does not specify a fixed dollar or satoshi fee.

While the tree remains active, each transition spends and recreates the shared output, so changes happen sequentially. If many members try to exit at once, transactions can queue; the final exit can remove the output. The design sets no activation or rollout schedule for the script changes it requires. A reference implementation and simulator, Lean-checked tree rules and 3,019 executable checks accompany the design.