We are already beginning to see the seeds of the second layer potential develop from the base layer primitives added or optimized in the first decade. Lightning is still subject to rather large restrictions, but it is truly beginning to thrive. And it is the limited first version currently specified and expanded. There are currently a wide variety of sidechains being deployed. It is a token chain linked to liquid, RSK and even Bitcoin developed by CommerceBlock. This is just the beginning.
Schnorr and Taproot
On the horizon there is a combination of Schnorr and Taproot. On the Schnorr side of things, this is much cheaper to verify the batch signature scheme, and the next big leap to optimize the configuration of Bitcoin's multi-signature scripts. Multisig started by simply including all the public keys and Multisig scripts in transaction output, all of which are used for input, to send it. P2SH optimizes aspects of output by including multisig public keys and a constant length hash of scripts, saving people's fees and increasing the cost of senders only. Segwit will undoubtedly be “optimized” by making MultiSig UTXOS cheaper with witness discounts. Schnorr takes all this incremental optimization to an extreme. Combine individual public keys into a single key. This allows everyone to collaborate to create a single signature and verify it. This generates a huge amount of cost savings for all use of multisigs, including second layers such as Lightning and Federated Sidechains, making all of these multisig UTXOs indistinguishable from those with a single signature. This creates privacy benefits.
Now it doesn't just make everything completely private like magic. Lightning Channel States (transactions) require a separate key path for penalty transactions to accommodate old state submissions. That is, they must be in the output script that creates the fingerprint. Taproot can resolve this with its crypto magic and commit the Merkle tree of various expenditure terms. This requires only the state in use and the Merkle proof, and requires Merkle proof in the Merkle route to use for normal-looking schnoll public keys. You can now hide that penalty script path in TapRoot. It is possible to hide conditional script paths in Taproot buried under the keys of the completely normal-looking shunt so that all participants can agree to something and create a transaction that looks completely normal. can.
Sighash_anyprevoutput
I hope that Sighash_anyprevoutput (formerly Sighash_noinput) is the next new primitive down the pipeline. This is a new public key format/Sighash flag upgrade. The Sighash flag specifies which part of the transaction the signature is committed to. This feature allows you to do things like signing only inputs and outputs, but allows others to add them to your transaction without disabling their inputs and outputs. But now the signature needs to be committed to just utxo from An just transaction. Sighash_anyprevout is especially effective Commit signatures to UTXO scripts onlynot a real specific UTXO. This allows the new method (Eltoo) to build lightning conditions that don't require penalty keys and deal with old states by allowing cheated parties to confiscate all their money. Instead, the current channel state can simply re-expend the old channel state if you lose the double spending race. You can accomplish that by simply reusing the same script in the right place and using Sighash_anyprevout.
This removes many risks of losing current channel state, resulting in penalty transactions funding for honest mistakes. It also allows for more. Now you can create lightning channels with two or more participants, and you can also stack “subchannels” on top of them. Also, Sighash_anyprevout and Eltoo allow for the creation of statuses that allow new participants to leave the chain completely, with the assumption of trust that the Federation will not conspire with past participants to fraudulent anyone. This opens up many possibilities for what I call “multiparty static UTXO protocol.”
op_checktemplateverify
OP_CTV is Jeremy Rubin's proposal, allowing for a very basic type of “contract” in Bitcoin. A contract is a more complicated limit for spending coins beyond signatures from a particular key. Rubin's proposal type is “template”. Essentially, this allows UTXO scripts to require that they create certain accurate outputs through spending transactions. Therefore, when UTXO is created using OP_CTV, it is forced by the consensus that UTXO should be used for a specific amount of specific addresses defined in that UTXO's script. You could also combine these together so that one of these Utxos is forced to make some of them.
This has vast general applicability everywhere. In high-price environments, a single UTXO can be created by entities detaining them. 100% under consensus rules It ensures that all of your client's funds are caught up in the control of your client, even if they are not immediately accessible at this time. This has many synergistic effects with multi-party channels (channel factories). This is because the massive “retreats” that are carried out in this way can also be created and used as channel factories. Can be created using OP_CTV A payment channel that functions unilaterally without having to participate or having a key online to receive payments (And don't forget that you can stack channels above each other). A single channel can also be used to allow more HTLCs to be handled at once by bundling them with the same tricks as the first example using a detained withdrawal. It can even create the possibility of a new type of coin join.
Putting it all together
Assuming that all the above proposals have been adopted and built into Bitcoin, aside from developers who are actually working on these cutting edges, people use what kind of protocols and protocols they have and I don't think they even have a small clue to build a service. Primitives. Or something strange that doesn't have a clear split line between services or protocols.
Theoretically, multiparty channels with unlimited number of participants can be enabled, and subchannels can be stacked on top with a small subgroup of participants in the base channel. Channels can be built on top of these “channel factories” and allow people to receive their money without having to prepare keys online for hot wallets. These multi-party channels themselves can be stacked on federated channels (state chains) where participants can enter or exit. Zero On-Chain Activities! The channel “splication” also allows fluidity to move relatively seamlessly between different channels in a way that allows for all sorts of things that people aren't actually beginning to think about.
My final words in this section are: This is to consider what you can do by considering the direct part of the Bitcoin Protocol stack itself. You can do much more when you start to look at centralized management services, and the subset of Bitcoin properties they can offer without refusing to regulatory or legal barriers.
This is part 2 of 4. Read the next part tomorrow.
