Bitcoin’s 2020 In Tech

Seemingly undisturbed by 2020’s craziness, and largely unfazed by bitcoin’s wild price swings that concluded with new all-time highs in December, Bitcoin’s technical community continues to plow ahead. Bitcoin’s software and the many projects around it were gradually improved throughout the year, as software was optimized, bugs fixed and privacy leaks patched. The bulk of this work, as vital as much of it is, doesn’t attract headlines.

Yet, a bird’s-eye view on Bitcoin’s tech development over the span of a year helps highlight new milestones in Bitcoin’s ongoing technological march forward. In 2020, too, the consistently growing Bitcoin development community introduced a number of useful new features, several particularly important upgrades and some especially notable improvements.

As this volatile year is drawing to a close, these were some of Bitcoin’s most notable technical developments over the past 12 months…

New Privacy Tools With PayJoin And CoinSwap

On Bitcoin’s privacy front, the PayJoin and CoinSwap projects this year represented two promising advancements.

PayJoin, also known as Pay to Endpoint (P2EP), is a trick that lets recipients of a transaction partake in the transaction through a CoinJoin, to basically send funds to themselves while also receiving the actual payment from the real sender. If a snoop, conducting blockchain analysis, were to assume that all coins sent in a transaction belonged to the same person — as they normally would — they’d be wrong. This already benefits the privacy of both sender and receiver, as the snoop would confuse (past) coin ownership between them. Moreover, if enough people use PayJoin, it could render this important heuristic for blockchain analysis useless altogether, in turn benefiting even the privacy of those who didn’t make PayJoin transactions themselves.

Although demo versions of the PayJoin tool had already been implemented for online gambling game Bustabit and the coin mixing software JoinMarket in late 2018, and Samourai Wallet in 2019 released its own — more limited — version under the Cohoots umbrella (with slightly different privacy tradeoffs), PayJoin was this year implemented in several popular Bitcoin projects. This notably included the widely used payment processing software BTCPay in April, allowing BTCPay users to accept PayJoin transactions from compatible wallets. The privacy-focused Wasabi Wallet was the first wallet to offer this compatibility later that same month, while JoinMarket (September), Blue Wallet (October) and Sparrow Wallet (November) followed later in the year.

Meanwhile, Bitcoin developer Chris Belcher set out to realize an implementation of CoinSwap, a privacy technique first proposed in 2013 by Bitcoin Core contributor Gregory Maxwell. CoinSwap leverages Atomic Swaps (the trick that also underpins the Lightning Network) to let users exchange coins without needing to trust one another. Each user would end up with coins that can’t be linked to their own transaction history.

Belcher, one of the world’s foremost experts in Bitcoin privacy, in May published a detailed outline of how the CoinSwap protocol could be implemented to ensure maximum privacy. The proposal would make CoinSwap transactions indistinguishable from other transactions, use splitting techniques to obscure amounts, route payments to frustrate snooping participants and more. A few months later, in June, The Human Rights Foundation announced that its first Bitcoin development grant would go to Belcher and his efforts to realize the project.

Having worked on his implementation for most of the year, Belcher in December announced a “big day for bitcoin privacy and fungibility”: he’d made the first-ever successful CoinSwap transaction on Bitcoin’s test network (testnet).

The Lightning Network Became More Robust With Watchtowers (And More)

The Lightning Network, Bitcoin’s Layer 2 protocol for faster, cheaper and more private payments, continued to improve across the board in 2020. With Lightning implementations LND, Eclair, C-Lightning and — since July — Electrum rolling out a number of new software releases, and a growing number of projects building on top of the protocol, Lightning development was more active than ever. Among the more notable developments, Watchtowers resolved one of the Lightning Network’s remaining weaknesses, resulting in a more robust protocol.

One of the Lightning Network’s tradeoffs is that users need to keep an eye on their payment channels to ensure that payment channel partners aren’t trying to cheat by broadcasting old channel states to claim more funds than attributed to them. Lightning users can step in if a channel partner attempts to cheat, but this does require monitoring of the Bitcoin blockchain, which casual users might not do very regularly.

To decrease the risk that an attempt at cheating is missed, the Lightning protocol allows channel monitoring to be outsourced to impartial observers called Watchtowers. Adding to the first Watchtower software introduced by LND by late 2019, February of this year saw the alpha release of the dedicated Watchtower implementation Eye of Satoshi. Shortly after, the proposed Watchtower protocol specification was updated, while C-Lightning rolled out support for Eye of Satoshi in May. Version 1 of Eye of Satoshi followed in July.

Other notable Lightning developments in 2020 include the continued work on anchor outputs to ensure users can claim funds from a channel unilaterally even when on-chain fees have gone up more than expected since the last payment channel update, Multipath payments which let users make Lightning payments in smaller chunks, the Lightning Network-native messaging application Juggernaut, channel management tool Faraday, the Lightning Loop beta release, but also some newly discovered weaknesses as well as (proposed) solutions, and a lot more more.

After Miniscript, Bitcoin Programming Was Made Easier With Minsc

The code embedded in Bitcoin transactions that specifies what conditions must be met to spend the coins in a next transaction is written in a programming language specifically designed for Bitcoin, called Script. Script can be tricky to work with, however: in programmers jargon, Script is hard to “reason about.” This means that, especially as it becomes a bit more complex, it can be difficult to understand what a piece of script actually allows: a transaction may unintentionally include code that allows the coins to be spent under different conditions than originally intended. This is one reason why many Bitcoin software applications, like wallets, refrain from utilizing Script’s full potential.

Over the past years, (former) Blockstream researchers Andrew Poelstra, Pieter Wuille and Sanket Kanjalkar designed a “stripped down” version of Script, called Miniscript. Miniscript is a selection of “tools” from the “Script toolkit” that are carefully selected to enable practically anything that can be done with Script, but it’s easier to use and easier to verify by programmers. So, while a line of Miniscript is still a valid line of Script, it essentially avoids human error by preventing unexpected, perhaps unintended, outcomes of the code; Miniscript is easier to reason about. In November of this year, Head of Research and Development at Rugged Bytes Dmitry Petukhov published a formal specification of Miniscript.

To make creating Bitcoin transactions even easier, Wuille had also designed a “policy language” for Miniscript, a programming language of its own that could compile (convert) into Miniscript, and thus Script. Building on Wuille’s work, Bitcoin developer Nadav Ivgi this year developed another new programming language called Minsc. First announced in July, and followed up with a major upgrade in November, Minsc is still a work in progress, but is set to greatly simplify the creation of Bitcoin transactions. This could help unlock a range of promising features that take full advantage of Bitcoin’s versatility, like interoperable CoinJoin wallets, smart contract solutions, Layer 2 protocols and more.

Smart Contracts Became Smarter With DLCs

Whenever smart contracts depend on external data — data that doesn’t live on the blockchain — they rely on an external source for that data referred to as an “oracle.” If two users want to bet on the outcome of a sports match, for example, the oracle would have to use the result of the match to settle the bet in favor of whoever made the correct prediction (at least in case of a dispute).

A very basic sports betting setup could consist of a two-of-three multisignature (multisig) address where both players and the oracle all hold one key each, and the oracle is informed of the details of the bet. After the match, the two players could cooperate to send the funds from the multisig to the winner without the oracle’s key. But if the loser refuses to cooperate, the oracle can use its third key to cooperate with the winner to send them the funds from the multisig. This system works, but has two main downsides. One, both players need to trust the oracle not to collude with their opponent. And two, the oracle needs to be informed of the bet and perhaps play an active part in the settlement process: this means players have no privacy from the oracle, while the setup doesn’t scale very well if more than a few players want to bet.

A better solution was in 2017 proposed by MIT Media Lab’s Digital Currency Initiative researcher Thaddeus Dryja: discreet log contracts (DLCs). DLCs use a clever mathematical trick where the oracle publishes a cryptographic signature that corresponds with the outcome of an event. In the example above, the oracle would publish one signature if the first team wins, and a different signature if the other team wins. The trick: the smart contract is designed to let the winning player use the published signature to claim the funds.

In a DLC, the oracle’s involvement with the smart contract is minimized to the publication of a signature; this could, in the sports betting example for instance, be done by an existing news service, as part of its regular broadcast. This also means that the oracle doesn’t need to be informed about the details of the bet, and in fact doesn’t even need to know there was a bet at all. Meanwhile, any number of people can use the signatures to settle their bets with no further involvement from the oracle, greatly benefiting scalability. And while oracle could in theory still collude with someone and broadcast the wrong result, such dishonest behavior would be obvious to anyone and tarnish the oracle’s reputation going forward.

In January of this year, CEO Chris Stewart announced that his company Suredbits, in collaboration with Crypto Garage, had begun work on a specification for DLCs. In February, Suredbits engineer Nadav Kohen followed up with the first working code. And by September, Suredbits and Crypto Garage had developed their software to the point where it could be used: Stewart and Bitcoin developer Nicolas Dorier engaged in Bitcoin’s first-ever DLC to bet on the outcome of the U.S. presidential election. Stewart, who’d bet on Biden, claimed his winnings in December.

Holding Is Getting Safer With Bitcoin Vaults

The long list of exchange hacks and other bitcoin heists are testament to the fact that securely storing private keys continues to be a challenge, especially where many coins are at stake.

But more secure solutions to store coins are in development. Bitcoin vaults — a concept dating back to 2016 — are a type of smart contract that secure coins so that it takes several confirmed transactions and a time delay to really spend them. This gives potential victims the opportunity to revert a heist before it is too late.

2020 saw the release of two types of vault prototypes.

The first vault prototype was announced by Bitcoin Core contributor Bryan Bishop in April. In short, Bishop’s design is based on a pre-signed (and not-yet-broadcast) transaction that spends (some of) the coins from the vault to a user’s regular (“hot”) wallet with a time-lock delay, while an alternative spending option without a timelock can redirect the coins to an alternative address; perhaps a new and even more secure vault. Importantly, the private key used to sign the pre-signed transactions is deleted when the vault is created, so an attacker could only ever steal the pre-signed transaction itself.

The setup makes it exceedingly difficult for an attacker to claim the coins. Even if the pre-signed transaction is stolen, the thief could merely spend the coins to the hot wallet, and if the victim doesn’t trust the security of his hot wallet he can use the baked-in time delay to move the coins to the extra-secure address instead. (To prevent the thief from stealing the coins by simply compromising the hot wallet and waiting patiently until the vault user sends his coins there, Bishop’s design only lets users withdraw from the vault in small chunks at the time.)

A little later in April, Bitcoin developer Antoine Poinsot announced an alternative Vault demo which he designed with Chainsmiths CEO Kevin Loaec, called Revault. Revault resembles Bishop’s Vaults in some ways, like its use of pre-signed transactions, but is specifically designed for multi-user setups, using a multisig address. Revault lets a predetermined subset of a group of users spend coins from the vault to a hot wallet, also with a time-delay. Any vault participant can use this time-delay to return the funds to the vault if they disagree with the spend, however, or they can redirect the funds to an alternative extra secure address if they don’t trust what’s going on at all.

In addition, Revault requires that upon withdrawing from the vault, when the time-lock kicks in, users immediately create a transaction from the hot wallet, which also requires a server to co-sign. The server is programmed to sign any transaction, but never a conflicting transaction, so if an attacker compromised (both the vault and) the hot wallet, they would have to try and claim the coins before anyone else and before the time-lock expires. This should make it obvious if the hot wallet is compromised, alarming the group of Revault users, and allowing them to redirect the funds before time-lock expiry.

Taproot Is Now Good To Go, As Activation Is Under Consideration

Taproot is set to be the first Bitcoin protocol upgrade since Segregated Witness activated in August 2017. First proposed by Bitcoin Core contributor Gregory Maxwell in January 2018, Taproot lets users “hide” smart contracts in regular-looking Bitcoin transactions: complex multisig construction could be indistinguishable from a simple payment.

The Taproot upgrade would also include the Schnorr Signature algorithm. Many cryptographers consider the Schnorr signature scheme to be the best in the field, as its mathematical properties offer a strong level of correctness, it doesn’t suffer from malleability and is relatively fast to verify. Schnorr’s “linear math” would also allow for a range of new possibilities, like more compact types of multisig solutions, nifty smart contract setups and, of course, Taproot itself.

After continued development throughout 2020, Taproot’s code was merged into the Bitcoin Core codebase in October, and will be part of Bitcoin Core 0.21.0, which is set to be released any day now, with release candidates currently available. Bitcoin Core 0.21.0 will not include activation logic for Taproot, however. This will likely be included in an upcoming minor Bitcoin Core release (probably Bitcoin Core 0.21.1).

The activation logic has itself been a topic of discussion throughout much of 2020, however, with a range of potential activation mechanisms under consideration. Most of these would initially leverage hash power coordination, to eventually reach a deadline where the upgrade activates even without hash power support. But as an October poll published by Bitcoin Core contributor AJ Towns made clear, not all Bitcoin Core contributors agree that the deadline should be pre-programmed, or how far out the deadline should be (as well as some other minor disagreements).

But regardless of which activation mechanism is ultimately chosen, it seems increasingly likely that Taproot can be activated smoothly through hash power coordination. In November, major mining pool Poolin launched an initiative encouraging other mining pools to voice their opinion on Taproot and Taproot activation. The response so far is very favorable of Taproot, with over 90 percent of total hash power in support, and no mining pools opposing the proposed upgrade.

For an even more extensive and detailed summary of Bitcoin’s 2020 tech developments, also see the Bitcoin Optech 2020 Year-in-Review Special.

The post Bitcoin’s 2020 In Tech appeared first on Bitcoin Magazine.

from Bitcoin Magazine https://ift.tt/34WRt9k