We are beginning to witness the emergence of second-layer possibilities that stem from the foundational advancements made during Bitcoin’s first decade. Lightning Network, although facing some significant challenges, is starting to flourish. This represents only the initial iteration that has been specified and implemented. Various sidechains, including Liquid, RSK, and token chains associated with Bitcoin created by Commerceblock, are already operational. This is merely the beginning.
Schnorr and Taproot
Ahead lies the introduction of Schnorr signatures and Taproot. Schnorr signatures will provide a more efficient method for batch verification, significantly enhancing the multi-signature script architecture within Bitcoin. Initially, multi-signature (multisig) solutions involved embedding all public keys and the corresponding scripts directly into the transaction output, necessitating their inclusion in the input as well. The introduction of P2SH improved this by allowing a fixed-length hash of the public keys and scripts to be included, resulting in reduced fees for transactions directed to multisig addresses, imposing costs primarily on the sender. SegWit built upon this by further lowering the costs associated with spending multisig UTXOs due to the witness discount. Schnorr, however, advances these optimizations to an exceptional level by allowing the combination of numerous public keys into a singular key, enabling all parties to collaborate in creating a unified signature. This transformation leads to considerable cost reductions in multisig usage, affecting second-layer solutions like Lightning and federated sidechains, while also enhancing privacy by rendering multisig UTXOs indistinguishable from single-signature transactions.
However, this does not inherently guarantee total privacy. Transactions involving Lightning channel states still necessitate separate key paths for their penalty scripts, which respond when older states are submitted. Consequently, these must be incorporated within the output scripts, creating recognizable patterns. Taproot addresses this with its sophisticated cryptographic method, allowing the commitment of a Merkle tree encapsulating various spending conditions, only requiring the activated condition and a Merkle proof to the root for expenditures tied to a standard Schnorr public key. This mechanism conceals penalty script paths with Taproot, along with any conditional script paths, nestled under an otherwise ordinary-looking Schnorr key that facilitates consensus among participants for typical transactions.
SIGHASH_ANYPREVOUTPUT
SIGHASH_ANYPREVOUTPUT (formerly known as SIGHASH_NOINPUT) is anticipated as the next groundbreaking primitive to be integrated. This upgrade introduces a new public key format along with a sighash flag. Sighash flags dictate which elements of a transaction the signature affirms. This feature allows users to sign individual inputs and outputs while permitting others to incorporate their inputs and outputs without invalidating the transaction. Currently, however, a signature is bound to an exact UTXO from a corresponding transaction. SIGHASH_ANYPREVOUT, among other innovations, could allow committing a signature merely to a UTXO script, rather than pinpointing a specific UTXO. This modifies how Lightning channel states are constructed, eliminating the need for a penalty key or managing outdated states by enabling the aggrieved party to claim all funds without penalty. Rather, the current channel state could simply respend the previous state if it loses the double-spending contention, ensuring everyone receives their up-to-date channel balance on-chain, rather than an outdated version. This is accomplished by reusing the same script appropriately coupled with SIGHASH_ANYPREVOUT.
The implications of this change are vast, reducing risks associated with losing current channel states and thereby averting unintended penalties that could confiscate funds due to honest errors. It also paves the way for channels involving more than two participants and the possibility of creating “sub-channels” layered on top. Additionally, SIGHASH_ANYPREVOUTPUT and eltoo facilitate the creation of Statechains, a federated channel construct that permits new members to join and exit entirely off-chain, based on the assumption that the federation will not conspire with prior participants to cheat anyone. This aspect opens new avenues for what I refer to as “multi-party static UTXO protocols.”
OP_CHECKTEMPLATEVERIFY
OP_CTV is a concept proposed by Jeremy Rubin aimed at facilitating a fundamental type of “covenant” within Bitcoin. A covenant establishes more complex restrictions on how a coin can be spent beyond mere signatures from specific keys. Rubin’s proposal focuses on implementing a “template” covenant, which mandates that a UTXO’s script necessitates certain exact outputs to be generated by the spending transaction. Consequently, once a UTXO is created using OP_CTV, consensus rules enforce that the UTXO must be spent to clearly defined addresses and amounts as specified in the script. Moreover, these can be linked together, ensuring that one UTXO compels the creation of additional ones, continuously cascading these stipulations.
The applications for this feature are substantial. In environments with elevated fees, a single UTXO can be established by a custodial service, which guarantees—under consensus rules—that all customer funds will ultimately come under the customers’ control, even if they cannot access them immediately. The synergy this creates with multi-party channels (channel factories) is significant, as a mass withdrawal executed in this manner can also enable the simultaneous establishment of a channel factory. OP_CTV can facilitate the creation of payment channels that function unidirectionally without requiring the receiving party to actively participate or maintain a key online for the duration of transactions(and it’s important to note that these channels can be layered). Furthermore, it can allow a singular channel to handle multiple Hashed Time-Locked Contracts (HTLCs) simultaneously by intelligently bundling them with the same method described earlier for custodial withdrawals. There’s potential here for new forms of coin joins as well.
Bringing It All Together
If all the aforementioned proposals are successfully adopted and integrated into Bitcoin, I believe that aside from the developers at the forefront of these advancements, many individuals will still struggle to grasp the depth of protocols and services that could be established using these primitives—some of which blur the line between service and protocol.
These innovations will allow for multi-party channels with potentially limitless participant numbers, along with the ability to create stacked sub-channels involving smaller subsets of the primary channel’s participants. Channels may be constructed on top of these “channel factories,” enabling users to receive funds without needing to keep a hot wallet online. Additionally, these multi-party channels could themselves be developed atop federated channels (statechains), allowing participants to enter or exit the system while maintaining zero on-chain activity! Furthermore, the concept of channel “splicing” will facilitate fluid liquidity movement among diverse channels, leading to possibilities that are still largely unexplored.
As I conclude this section, it is worth noting that this discussion is limited to what can be achieved strictly within the Bitcoin protocol stack. The potential broadens considerably when considering centralized custodial services and the range of properties that Bitcoin can offer while overlooking regulatory or legal obstacles associated with such services.
This marks Part 2 of 4; stay tuned for the next installment tomorrow.
