How do practitioners in 2010 view the BTC construction road ten years later

Author: BTC Podcast Block Digest co-founder Shinobi; translation: Wuzhu, Golden Finance

This article is written by Shinobi ten years ago, discussing what BTC was like in 2020.

The first article in this series can be viewed by clicking on "How do practitioners in 2010 view the BTC ecosystem ten years later?"

We have started to see the seeds of second-layer potential develop from the first decade's foundational layer primitives. While the Lightning Network is still subject to some fairly significant limitations, it is indeed starting to flourish. This is just the limited first version that is currently designated and deployed. Various types of sidechains have now been deployed: Liquid, RSK, and even a token chain bound to BTC developed by Commerceblock. This is just the beginning.

SCHNORR and TAPROOT

It wasn't long before we had a combination of Schnorr and Taproot. From Schnorr's point of view, this is a batch verification signature scheme that costs less and is the next major leap forward in optimizing the construction of BTC multisig scripts. A multisig is initially just a matter of sending it with all the public keys and multisig scripts stuffed into the transaction output, and all of this must be included in the input in order to use it. P2SH optimizes the output aspect by including a multisig public key and a constant-length hash of the script, saving anyone sending to a multisig address and only adding cost to the sender. SegWit arguably "optimizes" further by witnessing discounts to make UTXOs that cost multisig cheaper. Schnorr takes all of these incremental optimizations to the extreme. You combine individual public keys into a single key, and everyone can collaborate to make a signature for it and then check it. This provides significant cost savings for all technologies that use multisig, including Layer 2 such as Lightning Network (Lightning) and federated sidechains, and also brings privacy benefits by making all these multisig UTXOs indistinguishable from single-signature UTXOs.

Now, this does not magically make everything completely secret. Lightning channel state (transactions) still need separate key paths for their penalty transactions to react to old states submitted. This means that these must be in the output script that creates the fingerprint. Taproot solves this problem through its encryption magic, allowing you to submit a Merkle tree with different spending conditions, only needing the conditions used and Merkle proof to the Merkle root to spend, to a Schnorr public key that looks normal. Now, you can hide the penalty script path using taproot. You can hide any conditional script path using Taproot, hidden under what looks like a very normal Schnorr key, which allows all participants to agree on something and conduct transactions that look very normal.

SIGHASH_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT (formerly SIGHASH_NOINPUT) is expected to become the next new opcode. It is a new public key format/sighash flag upgrade. The Sighash flag specifies which parts of the transaction the signature will commit to. The existence of this feature is to allow you to perform operations such as signing only your inputs and outputs, but allow others to add their inputs and outputs to the transaction without invalidating it. But currently, the signature must commit to the exact UTXO from the exact transaction. Among other things, SIGHASH_ANYPREVOUT can commit the signature to the UTXO script rather than the actual specific UTXO. This allows for a new way (eltoo) to construct lightning channel states, without the need for penalty keys or dealing with old states, allowing the deceived party to confiscate all funds. Instead, if the current channel state fails in a double spend race, it can simply reuse the old channel state, ensuring that everyone can get their current channel balance on-chain instead of the previous expired balance. You can achieve this by simply reusing the same script in the right place and using SIGHASH_ANYPREVOUT.

This eliminates many risks, such as losing the current channel state, resulting in penalty transactions withholding your funds due to unintentional loss. It can also enable more functionality. Now, we can have Lightning channels with more than 2 participants, and even stack "sub-channels" on these channels. In addition, SIGHASH_ANYPREVOUT and eltoo can create Statechains, which is a collaborative channel construction that allows new participants to enter and exit completely off-chain, assuming that the alliance will not conspire with past participants to deceive anyone. This opens up a lot of potential for what I have always referred to as the "multi-party static UTXO protocol" protocol.

OP_CHECKTEMPLATEVERIFY

OP_CTV is a proposal put forward by Jeremy Rubin aimed at implementing a very basic 'contract' on BTC. The contract is a more complex restriction on the use of a BTC, not just a signature of certain keys. The type of contract to be implemented in Rubin's proposal is a 'template.' Essentially, this allows the script of a UTXO to require spending transactions to create specific exact outputs. Therefore, once a UTXO is created using OP_CTV, it is enforced by consensus, requiring the UTXO to be spent to a specific address with the amount defined in the UTXO script. You can even link them together so that one UTXO is forced to generate several more, and then these UTXOs are forced to generate several more, and so on.

This has broad universal applicability everywhere. In a high-fee environment, a custodial entity can make a single UTXO, which guarantees 100% of its clients' funds in accordance with consensus rules that all of its clients' funds will ultimately be controlled by the client, even if they do not currently have immediate access to those funds. This has great potential synergies with multi-channel (channel factory), as large-scale "withdrawals" like this can also be created and used as a channel factory at the same time. OP_CTV can be used to create payment channels that work in at least one direction, without the need for receiver involvement or having a key online to receive payments (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 once by bundling them together, using the same tricks as the first hosted withdrawal example. It might even create some potential for a new type of coinjoin.

Integrate all elements

Assuming all the above proposals are adopted and incorporated into BTC, I really think that, apart from the developers who are actually working on these cutting-edge projects, people don't even know what types of protocols and services will be built using these primitives. Or the strange things that there are no clear boundaries between services or protocols.

They will enable theoretically unlimited numbers of participants in multi-party channels that can stack sub-channels on top of smaller subsets of base channel participants. Channels can be built on top of these 'channel factories' to allow people to receive payments without the need to have the keys to an online hot wallet. These multi-party channels themselves can be stacked on top of union channels (state chains), allowing participants to enter or exit without on-chain activity being zero! The construction of channel 'splicing' will allow liquidity to move relatively seamlessly between different channels, enabling a variety of things that people have not even really considered yet.

My last sentence in this section is: This is just considering what can be done with what I consider to be part of the BTC protocol stack itself. If you start looking into centralized custody services, and what subsets of BTC these services can offer without being affected by regulatory or legal barriers, then you can do more.