Taproot is currently the most likely next upgrade for Bitcoin. It’s one of the few upgrades currently being worked on that users and developers hope to see activated on the network eventually.
All of these upgrades share a common theme that will likely be the theme of many future upgrades as well. This theme is to make contracts unicast, or more simply, move contract logic off-chain, and leave it to the user, rather than 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 features intact.
These types of upgrades and systems are perfect for Bitcoin. Bitcoin is simply a monetary network, not a computer network. Being a monetary network, its primary function should be to validate that its monetary system is properly maintained. In Bitcoin terms, checking that users have properly signed the transaction and that they have not violated monetary policy should be the primary function of the system, and everything else should be moved to higher tiers and done only between the users who Using Bitcoin for more than financial settlement.
MuSig and Unicast contracts
MuSig is one of the best understood uses of moving from contract logic to unicast. With MuSig, users can make a multisig output look like a standard user’s single sig output. This is done by having users construct keys and signatures outside of the chain and have them perform some cryptographic operations that result in a single public key and signature. This is a huge improvement over a normal multisig, which requires users to broadcast all their public keys and signatures. By doing a normal multisig, the users offload their contract validation to the network, requiring it to be validated and stored indefinitely. Instead, the users with a MuSig do the enforcement themselves by assembling signatures among themselves, resulting in a single final signature that can only be valid if the correct number of parties were fair, leaving the network to validate only a single signature and store.
Running contract logic in a unicast manner makes Bitcoin more private. Today, most contracts have their spending logic explicitly in the transaction output scripts. This means that an outside observer can see what the user’s exact spending terms are. If the user reveals their exact spending terms, it is not only harmful to the individual user, but also to the rest of the users on the network. By revealing all available spending paths, a user not only indicates that they are using them, but also shows that they are not using any other spending terms. This seems obvious, but has important implications. Because a user discloses that they don’t meet certain spending conditions, they are excluded from sharing an anonymity set of users using the other spending conditions. This means that the other users will not have our user in their anonymity, giving them a smaller crowd to hide under. If the user were to move their contract execution off-chain, the user could make their transactions and output look the same as that of a standard user and thus share an anonymity set with a larger group of users, enabling both themselves and the other users assisted.
Making the execution of a contract unicast not only makes Bitcoin more private, but also more scalable. By putting validation and execution logic outside the chain, which must be done by the individual users in the contract, ensures that they no longer have to send their entire contract to the entire network. By doing this, the network then no longer has to do the actual verification of what could be a complex contract, and instead only do the minimal verification, which is probably just a single signature check. Since the contract is no longer broadcast to the network, the network will not store the required data for this contract either. Due to Bitcoin’s block weight limit, reducing the data required for a transaction is a boon to the network as it instantly increases transaction throughput, allowing more to be done with the same amount of resources.
Eliminating the need to verify and store contract data can have a significant impact on how users use Bitcoin. With every Bitcoin transaction, the user has to pay a miner fee to be included in a block. This miner’s fee is directly correlated with the resources required to verify and save the transaction. Knowing this, we can conclude that users are discouraged from using complex scripts and spending terms. This can have bad consequences – for example, a user who tries to improve their security by using something like multisig to distribute their keys is now being penalized by the network for making them pay higher fees. Any improvements that can be made to this should be prescient for Bitcoin users and developers.
Using unicast-style contracts involves some other trade-offs as well. Since the user no longer transfers his contract validation and execution to the network, he will have to do this himself, or rather, the software he uses. This generally means that the user has to send and store more data between his counterparties. This requires more complex software and protocols for the user. It can make backups more critical and difficult; if the user loses this data, his counterparty may be in breach of his contract or, at the very least, the user cannot perform his contract without the cooperation of his counterparty. However, these are well understood problems and smart solutions are suggested to make data loss safer and even create ways to hide from a counterparty that data has been lost.
In conclusion, today Bitcoin contracts mainly exist as a broadcast system, where the network must validate and store the logic of everyone’s contract execution. Upgrades likely to come to Bitcoin could give us an outlook for contracts to be enforced between individual users instead, as Bitcoin is a monetary network first and should strengthen its monetary properties in the first place. Things like Taproot, Lightning, DLCs and PTLCs all illustrate this perfectly and show that Bitcoiners are building the ecosystem to improve Bitcoin’s privacy and scalability.
This is a guest post from Ben Carman. The views expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.