Off-Chain Contracts – Bitcoin Magazine

Taproot is currently the most likely next upgrade for Bitcoin. It is one of a few upgrades that are currently being worked on that users and developers would hope to eventually see activated on the network. 

All of these upgrades share a general theme that will likely be the theme of many future upgrades as well. This theme is making contracts unicast, or more simply put, moving contract logic off-chain, and leaving it up to the user, instead of the network, to validate and enforce their contract. Moving to a more unicast system will make Bitcoin much more private and scalable while still keeping Bitcoin’s more important properties intact.

These types of upgrades and systems are perfect for Bitcoin. Bitcoin is simply a monetary network, not a computation network. Being a monetary network, its primary function should be to validate that its monetary system is being correctly enforced. In Bitcoin terms, checking that users correctly signed the transaction and that they did not violate the monetary policy should be the primary function of the system, and anything more should be moved to higher layers and only done between the users that are using Bitcoin for more than financial settlement.

MuSig And Unicast Contracts

MuSig is one of the best understood applications of moving contract logic to be unicast. MuSig allows users to make a multisig output look like a standard user’s single sig output. This is done by having users construct keys and signatures off-chain and having them do some cryptographic operations that result in a single public key and signature. This is a huge improvement compared to a normal multisig, where the users need to broadcast all of their public keys and signatures. By doing a normal multisig, the users offload their contract validation to the network, requiring it to validate and store it indefinitely. Instead, with a MuSig, the users do the enforcement themselves by constructing signatures between themselves resulting in a single final signature that can only be valid if the correct amount of parties were honest, thus only requiring the network to validate and store a single signature.

Moving contract logic to be done in a unicast manner makes Bitcoin more private. Today, most contracts have their spending logic explicitly in the transaction’s output scripts. This means that an outside observer is able to see what the user’s exact spending conditions are. Having the user reveal their exact spending conditions not only harms the individual user but also affects the rest of the users on the network. By revealing all available spending paths, a user not only outs themselves as using them, but also reveals that they are not using other spending conditions. This seems obvious but has important implications. Because a user is revealing that they do not have certain spending conditions, it excludes them from sharing an anonymity set from users that use the other spending conditions. This means that the other users will not have our user in their anonymity set, giving them a smaller crowd to hide among. If the user moved their contract enforcement off-chain, then the user could make their transactions and outputs look the same as a standard user’s and thus share an anonymity set with a larger set of users, helping themselves as well as the other users.

Not only does making contract execution unicast make Bitcoin more private, it also makes it more scalable. Moving validation and execution logic off-chain, to be done by the individual users in the contract, ensures that they no longer need to broadcast their entire contract to the entire network. By doing so, the network will then no longer need to do the actual verification of what could be a complex contract and instead only do the minimal verification, likely being only a single signature check. Since the contract is no longer being broadcast to the network, the network will not be storing the required data for this contract either. Because of Bitcoin’s block weight limit, reducing the data needed for any transaction is a boon for the network as it will directly increase transaction throughput, allowing more to be done with the same amount of resources.

Tradeoffs

Removing the need to verify and store contract data can have significant impacts on how users use Bitcoin. With any Bitcoin transaction, the user will need to pay a miner fee to be included in a block. This miner fee is directly correlated to the resources needed to verify and store the transaction. Knowing this, we can conclude that users are disincentivized to use complex scripts and spending conditions. This can have bad implications — for example, a user who is trying to enhance their security by using something like multisig to distribute their keys is now being punished by the network for doing so by having them pay higher fees. Any improvements that can be made to this should be prescient to Bitcoin users and developers.

See Also

Using unicast-like contracts includes some other tradeoffs as well. Because the user is no longer offloading their contract validation and execution to the network, they will instead be required to do this themselves, or rather, the software they are using will be. This generally means that the user will need to send and store more data between their counterparties. Doing so requires more complex software and protocols for the user. It can make backups more critical and harder to do; if the user loses this data, their counterparty may be able to violate their contract or, at the very least, the user might not be able to execute their contract without their counterparty’s cooperation. However, these are well understood problems and clever solutions are being proposed to make loss of data safer and to even create ways to hide from a counterparty that there was a loss of data.

In conclusion, today, Bitcoin contracts primarily exist as a broadcast system, requiring the network to validate and store everyone’s contract execution logic. Upgrades that are likely coming to Bitcoin are able to give us an outlook that moves contracts to instead be enforced between individual users, since Bitcoin is a monetary network first and should primarily enforce its monetary properties. Things like Taproot, Lightning, DLCs and PTLCs all exemplify this perfectly and show that Bitcoiners are building the ecosystem to enhance Bitcoin’s privacy and scalability.

This is a guest post by Ben Carman. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Ben Carman

Developer at Suredbits, working on all things Bitcoin, Lightning and DLCs.

Source