Crypto News Updates

The Future Of Bitcoin Upgrades: Off-Chain Contract Execution

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.


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.

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.

The post The Future Of Bitcoin Upgrades: Off-Chain Contract Execution appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

DLCs Are On Bitcoin, Bringing New Functionality And Major Potential

Bitcoin has been critiqued by those in the altcoin community for the past few years over its inability to host smart contracts. But recent work from developers at Suredbits, Crypto Garage and Atomic Loans — along with efforts from some independent contributors — on Discreet Log Contracts (DLCs) is bringing smart contracting to Bitcoin and will quell some of these critics. DLCs are uniquely positioned to bring smart contracting to Bitcoin using oracle contracts that are much more private and scalable than previously thought possible.

What Are DLCs?

DLCs are Bitcoin-based contracts that use one or many oracle signatures for enforcement. The original proposal for DLCs was made by Tadge Dryja in 2017 and later redesigned to make them more scalable and private by using something called adaptor signatures. DLC oracle contracts allow for users to make a Bitcoin transaction contingent on an oracle’s signature. Using DLCs, Bitcoiners can make bets based on events to which the oracle is attesting. Last week, we saw one of the first of these done by Suredbits Founder Chris Stewart and creator of BTCPay Server Nicolas Dorier, betting on the result of the U.S. election.

After a recent DLC redesign, they were changed to use a 2-of-2 multisig that pays out directly to a user’s wallet instead of paying to a tweaked public key. This old design required a penalty mechanism similar to that of the Lightning Network, which made it take more block space and be less private. This redesign is made possible by using adaptor signatures and making the adaptor point based on the oracle’s expected signature. What this basically means is that each party gives each other invalid transaction signatures that can only be made valid in conjunction with the oracle signature.

To make this recent bet between Stewart and Dorier possible, a lot of progress has been made in developing a standard for DLCs as well as building software according to these standards. DLC developers have been working on this standard heavily since the beginning of this year. Along with this specification, they have been building compatible software; so far there are four major implementations being worked on: Bitcoin-S, NDLC, Rust-DLC and CFD-DLC.

The Future Of DLCs

The teams working on DLCs have lots of plans for the future of the technology. Today, DLCs have only been implemented for onchain transactions. One of the most obvious improvements for DLCs would be to put them on the Lightning Network! 

There are two planned ways to put DLCs on Lightning. One is by making them only usable between parties who already have Lightning channels open between one another, which could be done today but would require a lot of work done by the different Lightning implementations to add support for DLCs. 

And this could be obsoleted by the second way to do Lightning DLCs, however there are some caveats. This second way to do Lightning DLCs likely won’t be possible until after Taproot is activated, but it would allow these DLCs to be routed across a network and would remove the requirement to have a channel with a user’s counterparty, however this setup requires barrier escrows which have no known major implementations.

There are other general improvements to DLCs that can be made possible in the future as well. One major idea is to give the user the ability to use multiple oracles for a given contract instead of just one. This would allow users to distribute trust between multiple oracles, instead of having a single point of failure for their contracts. 

And other small improvements can be made come Taproot! With Taproot, we can make multisig transactions look like everyday, single sig transactions. Applying this to DLCs, we can make them have a smaller on-chain footprint and make them look like any other standard single sig transaction, thus saving users on fees and privacy!

DLCs are a pivotal new way to bring smart contracting to Bitcoin and we are extremely excited to see continued development with them. If you are interested in knowing more about DLCs, check out Suredbits’s blog and if you want it come contribute checkout the DLC specification repo!

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

The post DLCs Are On Bitcoin, Bringing New Functionality And Major Potential appeared first on Bitcoin Magazine.

Source: Bitcoin magazine