We’re already starting to see the seeds of second layer potential develop from the base layer primitives that have been added or optimized in the first decade. Lightning, while still subject to some pretty big limitations, is really starting to thrive. And that is just the limited first version that is currently specified and deployed. There are now sidechains of various kinds deployed: Liquid, RSK, and even token chains tied to Bitcoin developed by Commerceblock. This is just the start.
Schnorr and Taproot
Just over the horizon, we have the combination of Schnorr and Taproot. On the Schnorr side of things, this is a much cheaper to verify signature scheme in batches, as well as the next big leap in optimizing the construct of multi-signature scripts in Bitcoin. Multisig started out as just stuffing all the public keys and script for the multisig in a transaction output to send to it, and having to include all of that in the input to spend it. P2SH optimized the output aspect, by including a constant length hash of the public keys and scripts of the multisig, saving fees for anyone sending to a multisig address and leaving an increased cost only for the sender. SegWit arguably “optimized” further by making spending multisig UTXOs cheaper with the witness discount. Schnorr takes all this incremental optimization to the extreme. You combine the individual public keys into a single key, which everyone can collaborate to make a single signature for, and just check that. This creates massive cost savings for all use of multisig, including second layers like Lightning and federated sidechains, and creates a privacy benefit as well by making all of these multisig UTXOs indistinguishable from single signature ones.
Now that doesn’t just magically make everything completely private. Lightning channel states (transactions) still require separate key paths for their penalty transactions to react to submission of old states. That means those have to be in the output scripts which creates a fingerprint. Taproot solves this with its crypto-magic allowing you to commit a merkle tree of different spending conditions, that require only the condition used and merkle proof to the merkle root to spend, to a normal looking Schnorr public key. Now you can hide that penalty script path with taproot. You can hide any conditional script path with Taproot, buried underneath a perfectly normal looking Schnorr key that allows all participants to agree on something and make a perfectly normal looking transaction.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (previously SIGHASH_NOINPUT) is hopefully the next new primitive to come down the pipeline. It is a new public key format/sighash flag upgrade. Sighash flags specify which parts of a transaction a signature is committing to. This functionality is there so that you can do something like sign just your input and outputs, but allow other people to add their own inputs and outputs to a transaction without invalidating it. But currently, a signature has to commit to an exact UTXO from an exact transaction. SIGHASH_ANYPREVOUT, among other things, would enable committing a signature to just a UTXO script, not an actual specific UTXO. This allows a new way (eltoo) to construct Lightning channel states that does not require a penalty key or deal with old states by allowing the cheated party to confiscate all the money. Instead, the current channel state could simply re-spend the old channel state if it lost the double spend race, guaranteeing everyone gets their current channel balance on chain as opposed to a prior outdated balance. You accomplish that by just re-using the same script in the right place and using SIGHASH_ANYPREVOUT.
This removes a lot of risks regarding you losing current channel states resulting in a penalty transaction taking your funds for an honest mistake. It also enables MUCH more. Now we can have Lightning channels with more than 2 participants, and can even stack “sub-channels” on top of those. Also, SIGHASH_ANYPREVOUT and eltoo enable the creation of Statechains, a type of federated channel construct that allows new participants to enter and exit completely off chain with the trust assumption that the federation will not collude with past participants to defraud anyone. This opens a lot of potential for what I’ve been calling to myself “multi-party static UTXO protocols.”
OP_CHECKTEMPLATEVERIFY
OP_CTV is a proposal by Jeremy Rubin to enable a very basic type of “covenant” on Bitcoin. A covenant is more complicated restrictions to spending a coin beyond signatures from certain keys. The type of covenant Rubin’s proposal would implement is a “template.” Essentially, this allows a UTXO’s script to require specific exact outputs to be created by the spending transaction. So once a UTXO is created using OP_CTV, it is enforced by consensus that the UTXO has to be spent to specific addresses in the specific amounts defined in that UTXO’s script. You can even chain these together so that one of these UTXOs is forced to make a few more of them, which are then forced to make a few more, on and on.
This has enormous general applicability all over the place. In high fee environments, a single UTXO can be made by a custodial entity that 100% under consensus rules guarantees all of their customers funds will wind up under their customers control, even though they don’t have immediate access to them in the moment. This has a lot of potential synergy with multi-party channels (channel factories), in that a mass “withdrawal” done like this can also simultaneously create and be used as a channel factory. OP_CTV can be used to create payment channels that at least work uni-directionally without the receiving end having to participate or have a key online to receive payments (and remember you can stack channels on top of each other). It can even be used to allow a single channel to process more HTLCs at one time by bundling them together with the same trick that first example with custodial withdrawals uses. And might even create some potential for new types of coinjoins.
Putting Everything Together
Assuming all the above proposals are adopted and incorporated into Bitcoin, I really think that aside from the developers actually working on the leading edge of these things, people don’t even have the faintest clue what types of protocols and services will be built using these primitives. Or the weird things where there is no clear dividing line between service or protocol.
They will enable multi-party channels with theoretically unbounded participant numbers, that can stack sub-channels on top with smaller sub-groups of the participants of the base channel. Channels can be built on top of these “channel factories” that allow people to receive money without having keys online for a hot wallet. These multi-party channels can themselves be stacked on top of federated channels (statechains) that allow participants to enter or exit with zero on-chain activity! And the construct of channel “splicing” will allow liquidity to move relatively seamlessly between different channels in ways that will enable all kinds of things people haven’t even really began thinking about.
My last word in this section is: this is only considering what can be done with things I consider direct parts of the Bitcoin protocol stack itself. You can do a lot more if you start looking at centralized custodial services, and what subset of Bitcoin’s properties those can provide ignoring regulatory or legal barriers from doing so.
This is just Part 2 of 4, read the next part tomorrow.
