Categories
Crypto News Updates

Taproot Activation Brings Massive Upgrades To Bitcoin

Taproot brings new optimizations to security and usability to the Bitcoin network as the activation is locked in.

By the time this is published, Taproot will be locked-in for activation. This means that on block 709,632 (mid-November 2021), the new rules defined by a series of Bitcoin Improvement Proposals (BIPs) will be activated and start being enforced. This is a momentous achievement for Bitcoin and will enable so many awesome new things for not just Bitcoin but everything built on top of it, too.

Previously, it was debated if Bitcoin could come to consensus on another soft fork after the drama behind the 2017 SegWit upgrade. This previous soft fork spun out multiple camps that hard forked from the original Bitcoin chain, creating new altcoins. Meanwhile, the Bitcoin community was left with deep battle scars after months of debating and fighting for what resulted in a user activated soft fork (UASF).

It’s been almost four years since SegWit activated and people were skeptical that the Bitcoin community could overcome these battle scars for the next upgrade to Bitcoin. However, we have done it! It was a long process of debating on pull requests (PRs), Internet Relay Chat (IRC) channels, and Twitter, but it has finally come to a close.

Taproot as an upgrade had virtually no push back; by and large every core developer agreed with the consensus changes proposed in BIP340, BIP341 and BIP342. These BIPs propose changes that add privacy and optimizations as well as enabling new features in the future without any new security assumptions. Taproot by itself is a no-brainer upgrade to the Bitcoin protocol. The controversy came in when the discussions started on how to activate Taproot.

The controversy began with BIP8 which was created in response to what happened with SegWit. It made two changes to BIP9, the activation method used for SegWit. The first change was to define the start and end times of the activation by block height instead of real-world time. This makes defining the activation window slightly better because we aren’t reliant on blocks having exactly a 10-minute block time but with the tradeoff of being worse for test networks.

The second change was to add an optional user activated soft fork (UASF) at the end of the activation, known as lock-in-on-timeout or LOT. Both of these changes sparked heavy debate on if they should be made and resulted in many PRs being opened and closed to Bitcoin Core. The LOT parameter was eventually thrown out and replaced with a procedure called Speedy Trial.

Speedy Trial was proposed to break the stalemate between the two camps arguing over how to set LOT (true vs false). Speedy Trial described a three-month activation window instead of a one-year window, but with a minimum activation height that would be further in the future and with no UASF. This was structured so that we could either activate quickly or fail quickly. If we were to fail quickly, we could go back to debating. Or if we did activate quickly, the surrounding ecosystem would have more time to prepare for the upgrade.

Most developers agreed to try Speedy Trial which led to two PRs being opened to Bitcoin Core, one by Andrew Chow and another by A.J. Towns. Chow’s PR proposed using block height while Towns’ used real-world time. This led to further debate and lots of discussion on IRC that was eventually settled with Chow and Towns agreeing to move forward with Towns’ proposal.

All of this debate finally led to the culmination of Taproot being able to activate. Then we just needed miners to signal, which happened relatively quickly. Alejandro De La Torre, vice president of Poolin, had already gotten mining pools to commit to saying they would signal. However, at the start only Slush Pool was signaling. The plebs took to the streets and made memes donning green squares, a reference to taproot.watch’s way of showing which blocks signaled for activation and which did not. However, after only three difficulty adjustment periods we have achieved almost 99% of the hash power from miners signaling and have locked in the activation of Taproot.

Now that we can confidently say that Taproot will be part of the Bitcoin protocol, we should know what this will mean for Bitcoin and its many layers. As stated in the beginning, Taproot brings privacy and optimizations while allowing for new features in the future.

Taproot is able to add privacy to Bitcoin by allowing users to create multiple spending rules for their funds, but they only need to reveal the rules that were used for that transaction. In some cases there is no need to reveal there ever were other spending rules. The average Bitcoin user today doesn’t have a need for these sorts of complex rule scripts. However, most scaling solutions in Bitcoin do. Layers such as the Lightning Network, Liquid, and other sidechains all use scripted rules like multisig, hash time locks, and other tools to make their system secure. Today this all needs to be put on chain and revealed to the entire network. With Taproot this information no longer needs to be revealed all the time and transactions like Lightning channel opens can look exactly like a normal user’s transactions. So not only will it benefit Lightning users but it will benefit everyone as the general anonymity set of Bitcoin will grow, making privacy-compromising chain analysis harder to do.

Along with all these privacy improvements are lots of optimizations. Since we no longer need to reveal as much information on-chain, transactions will use less data and thus will reduce fees. This also means that more transactions will fit in each block and every unspent transaction output (UTXO) will be that much more efficient.

Not only do we get space-saving optimizations from Taproot, but we also get optimizations that will help with the speed of verifying transactions. Today, Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for signing transactions, but Taproot adds a new way to sign called Schnorr signatures. Schnorr signatures enable some of the space-saving optimizations we talked about while also being faster to verify, so running a full node will be less resource intensive with the same transaction throughput if Taproot sees significant adoption.

Taproot will also enable many new use cases and features. Something that has been talked about for awhile is Point Time Lock Contracts (PTLCs). PTLCs are a change to the Lightning Network that enable developers to build more complex applications on top of Lightning like Discreet Log Contracts, stuck-less payments and more. Taproot also allows for much less invasive upgrades in the future. Taproot left many new upgrade paths that we are already seeing people write proposals to use, namely SIGHASH_ANYPREVOUT. This should make the next Bitcoin soft fork happen more quickly and be less controversial as it will not carry as much weight as the upgrades before it.

In conclusion, Bitcoin has upgraded and has taken a step forward in making privacy better for its users. This did not come easy and it certainly shouldn’t have. However, now it’s time to celebrate and then start building.

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.

Source: Bitcoin magazine

Categories
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.

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.

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

Categories
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