Author: Bitcoin podcast Block Digest Lianchuang Shinobi; Translated by: Wuzhu, Golden Finance

This article is an article written by Shinobi ten years ago, discussing the fact that Bitcoin is in 2020 What's it.

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

We have begun to see the seeds of the second layer of potential develop from the basic layer primitives of the first decade. The Lightning Network, while still subject to some considerable restrictions, did begin to flourish. This is just the limited first version currently specified and deployed. Various types of sidechains have been deployed now: Liquid, RSK, and even a token chain developed by Commerceblock that is bound to Bitcoin. This is just the beginning.

Soon after, we had a combination of Schnorr and Taproot. From Schnorr's perspective, this is a batch verification signature solution with a lower cost and is also the next major leap in optimizing the construction of Bitcoin's multi-signature scripts. Multi-signatures initially just stuff all public keys and multi-signature scripts into the transaction output and send them to it, and all of this must be included in the input to use it. P2SH optimizes the output aspect by including the public key of the multi-signature and the constant-length hash of the script, saving money for anyone sent to the multi-signature address and adding only to the sender. SegWit can be said to be further "optimized" by witnessing discounts to make spending multi-signature UTXO cheaper. Schnorr takes all these incremental optimizations to the extreme. You combine individual public keys into a key, and everyone can collaborate to make a signature as it, and then check it out. This saves a lot of money on all technologies that use multi-signatures, including the second layer of Lightning and joint sidechain, and also brings privacy benefits by making all of these multi-signature UTXOs indistinguishable from single-signature UTXOs .

Now, this doesn't magically keep everything completely secret. Lightning channel states (transactions) still require a separate key path so that they punish transactions to react to commits of the old state. This means that these must be in the output script that creates the fingerprint. Taproot solves this problem with its encryption magic, allowing you to submit a merkle tree with different spending conditions, which only requires the conditions and merkle proof to the merkle root to spend, to the Schnorr public key that looks normal. You can now use taproot to hide the penalty script path. You can use Taproot to hide any conditional script path, hidden in Schns that look very normalUnder the orr key, this key allows all participants to agree on something and make transactions that seem very normal.

SIGHASH_ANYPREVOUTPUT (formerly SIGHASH_NOINPUT) is expected to be the next new primitive. It is the new public key format/sighash flag upgrade. The Sighash flag specifies which parts of the transaction will be submitted to. This feature exists to allow you to perform operations such as signing only your inputs and outputs, but allows others to add their own inputs and outputs to the transaction without invalidating it. But for the time being, the signature must be submitted to the exact UTXO from the exact transaction. Among other things, SIGHASH_ANYPREVOUT can submit signatures to UTXO scripts instead of actual specific UTXOs. This allows a new way to build lightning channel states without penalizing the key or processing the old state, allowing the scam party to confiscate all funds. Conversely, if the current channel state fails in a double payment competition, it can simply reuse the old channel state, ensuring that everyone can get their current channel balance on the chain instead of the previous expired balance. You can do this by simply reusing the same script in the right place and using SIGHASH_ANYPREVOUT .

This eliminates many risks, such as your loss of current channel status, resulting in a fine transaction withheld your funds due to unintentional mistakes. It can also implement more features. Now we can have lightning channels of more than 2 participants, and even stack "subchannels" on top of them. Additionally, SIGHASH_ANYPREVOUT and eltoo can create Statechains, a joint channel construct that allows new participants to enter and exit completely off-chain, and assumes that the alliance will not conspire with past participants to deceive anyone. This opens up a lot of potential for what I have always called the “multi-party static UTXO protocol.”

OP_CTV is a proposal proposed by Jeremy Rubin to implement a very basic "contract" on Bitcoin. The contract is a more complex restriction on the use of a BTC, not just the signature of certain keys. The type of contract that Rubin's proposal will implement is "template". Essentially, this allows UTXO's scripts to require spending transactions to create specific precise outputs. Therefore, once a UTXO is created using OP_CTV, it is enforced via consensus, i.e., the UTXO must be spent to a specific address, the amount defined in the script for that UTXO. You can even link them together so that one of the UTXOs is forced to generate a few more, and then these UTXOs are againForced to generate several, repeating this way.

This has widespread universal applicability anywhere. In a high-expense environment, a custodial entity can create a single UTXO that is 100% guaranteed by consensus rules that all of its customers’ funds will eventually be controlled by the customer, even if they currently do not have immediate access to the funds. This has a great potential synergy with multiple channels (channel factories), because large-scale "withdrawals" such as this can also be created and used as channel factories at the same time. OP_CTV can be used to create payment channels that work at least one-way without receiving end participation or having a key online to receive payments (remember, you can stack channels together). It can even be used to allow a single channel to process more HTLC at once by bundling them together, using the same tricks as the first managed withdrawal example. It may even create some potential for new types of coinjoin.

Assuming all the above proposals are adopted and included in Bitcoin, I really think that people don't even know what to build with these primitives, except for developers who are actually working on these cutting-edge jobs Types of protocols and services. Or something strange that has no clear dividing line between services or agreements.

They will enable multi-party channels with theoretically unlimited number of participants that can stack sub-channels on top of smaller subgroups of underlying channel participants. Channels can be built on top of these "channel factories" so that people can collect payments without having the key to their hot wallets online. These multi-party channels themselves can be stacked on top of a joint channel (status chain), allowing participants to enter or exit with zero on-chain activity! The structure of channel “stitching” will allow liquidity to move relatively seamlessly between different channels, thus achieving various things that people have not even really started to think about.

The last sentence I said in this section is: This is just about what you can do with what I think is a direct component of the Bitcoin protocol stack itself. If you start looking at centralized custodial services and what subsets of Bitcoin these services can offer without being affected by regulatory or legal barriers, then you can do more.