The Van Wirdum Sjorsnado 36 — Speedy Trial And The LOT=True Client   In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discussed the final implementation details of Speedy Trial, the Taproot activation mechanism included in Bitcoin Core 0.21.1. Van Wirdum and Provoost also compared Speedy Trial to the alternative BIP 8 LOT=true activation client. After more than a year of deliberation, the Bitcoin Core project has merged Speedy Trial as the (first) activation mechanism for the Taproot protocol upgrade. Although van Wirdum and Provoost had already covered Taproot, the different possible activation mechanisms and Speedy Trial specifically in previous episodes, in this episode they laid out the final implementation details of Speedy Trial.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss SIGHASH_ANYPREVOUT, a proposed new sighash flag that would enable a cleaner version of the Lightning Network and other Layer Two protocols.Sighash flags are included in Bitcoin transactions to indicate which part of the transaction is signed by the required private keys, exactly. This can be (almost) the entire transaction, or specific parts of it. Signing only specific parts allows for some flexibility to adjust the transaction even after it is signed, which can sometimes be useful.Aaron and Sjors explain that SIGHASH_ANYPREVOUT is a new type of sighash flag, which would sign most of the transaction, but not the inputs. This means that the inputs could be swapped, as long as the new inputs would still be compatible with the signature. SIGHASH_ANYPREVOUT would be especially useful in context of Eltoo, a proposed Layer Two protocol that would enable a new version of the Lightning Network. Where Lightning users currently need to store old channel data for security reasons, and could also be punished severely if they accidentally broadcast some of this data at the wrong time, Aaron and Sjors explain how SIGHASH_ANYPREVOUT would do away with this requirement.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss the Erlay protocol. Erlay is a proposal to reduce the bandwidth required to run a Bitcoin node, which has been proposed and developed by University of British Columbia researchers Gleb Naumenko, Alexandra Fedorova and Ivan Beschastnikh; Blockstream engineer Pieter Wuille; and independent Bitcoin Core contributor Gregory Maxwell. Bitcoin nodes use bandwidth to receive and transmit both block data as well as transaction data. Reducing the amount of bandwidth a node requires to do this, would make it cheaper to run a node. Alternatively, it allows nodes to connect to more peers without increasing its bandwidth usage.   In the episode, Aaron and Sjors explain that Erlay uses set reconciliation to reduce the amount of data nodes need to share transactions. More specifically, Erlay uses a mathematical trick called Minisketch. This solution is based on pre-existing mathematical formulas used in biometrics technology. Aaron and Sjors outline how this trick is applied in the context of Bitcoin to let different nodes sync their mempools: the sets of transactions they’ve received in anticipation of a new block, or, in the case of a miner, to include in a new block.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost are once again joined by Ruben Somsen. The trio discusses RGB tokens, a Layer Two protocol for Bitcoin to support alternative currency and token schemes (like the currently popular non-fungible tokens, or NFTs). Aaron, Sjors and Ruben explain that the Bitcoin blockchain has been (ab)used by users to host data since the project’s early days. This was initially done through otherwise-useless transaction outputs, which meant that all Bitcoin users had to store this data locally. A feature called OP_RETURN later limited this burden.They also explain that people have been using the Bitcoin blockchain to host alternative currency and token schemes for a long time.  More resources on RGB Tokens: https://youtu.be/PgeqT6ruBWU  

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Segregated Witness, also known as SegWit. SegWit was the last soft fork to have been activated on the Bitcoin network in the summer of 2017, and the biggest Bitcoin protocol upgrade to date. In short, SegWit allowed transaction data and signature data to be separated in Bitcoin blocks. In this episode, Aaron and Sjors explain how this works, and that this offered four main benefits: First, SegWit solved the transaction malleability issue, where transaction IDs could be altered without invalidating the transactions themselves. Solving the transaction malleability issue itself in turn enabled second layer protocols like the Lightning Network. Second, SegWit offered a modest block size limit increase by discounting the “weight” of witness data, most notably signatures. Importantly, this could be done without the need for a hard fork. Third, SegWit’s script versioning allows for easier upgrades to new transactions types. The anticipated Taproot upgrade could be a first example of this feature. And fourth, input signing resolved some edge case problems where wallets needed to make sure they don’t overpay in transaction fees.. Hardware wallets benefit from this solution in particular.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Speedy Trial, the proposed Taproot activation mechanism that has been gaining traction in recent weeks. Aaron and Sjors explain that Speedy Trial would give miners three months to signal support for the Taproot upgrade with their hash power. If a supermajority of miners signal support for the upgrade within these thee months, Taproot will activate a couple of months later: six months since the release of the software client that includes the activation logic. If miners don’t signal support within three months, the upgrade will expire, and a new upgrade path can be considered. (It is as of yet not defined what the potential alternative upgrade path would look like.) Aaron explains that Speedy Trial was born out of a compromise between developers and users who preferred different upgrade mechanisms for the Taproot soft fork, while Sjors details what some of the more technical implementation considerations of Speedy Trial are, like the benefits of using block heights instead of time stamps, and the extended delay between signaling and enforcement. Finally, Aaron and Sjors discuss some of the downsides and risks of Speedy Trial.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss hardware wallet integration into Bitcoin Core, one of the ongoing projects that Sjors regularly contributes to himself. Hardware wallets are a popular solution for storing private keys offline, to minimize the risk that hackers gain access to the corresponding coins. They are used in combination with regular software wallets to sign transactions in such a way that the private keys never leave the device.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss activation of the Taproot soft fork upgrade, and more specifically, the lock-in on timeout (LOT) parameter. The LOT parameter can be set to either “true” (LOT=true) or “false” (LOT=false). LOT=false resembles how several previous soft forks were activated. Miners would have one year to coordinate Taproot activation through hash power; if and when a supermajority (probably 90 percent) of miners signal readiness for the upgrade, the soft fork will activate. But if this doesn’t happen within (probably) a year, the upgrade will expire. (After which it could be redeployed.)LOT=true also lets miners activate the soft fork through hash power, but if they fail to do this within that year, nodes will activate the soft fork regardless.Aaron and Sjors discuss the benefits and detriments of each option. This also includes some possible scenarios of what could happen if some users set LOT to true, while other users set LOT to false, and the associated risks. Finally, Aaron and Sjors discuss what they think is most likely going to happen with Taproot activation.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Bitcoin addresses. Every Bitcoin user has probably at one point used Bitcoin addresses, but what are they, exactly? Aaron and Sjors explain that Bitcoin addresses are not part of the Bitcoin protocol. Instead, they are conventions used by Bitcoin (wallet) software to communicate where coins must be spent to: either a public key (P2PK), a public key hash (P2PKH), a script hash (P2SH), a witness public key hash (P2WPKH), or a witness script hash (P2WSH). Addresses also include some meta data about the address type itself. Bitcoin addresses communicate these payment options using their own “numeric systems”, Aaron and Sjors explain. The first version of this was base58, which uses 58 different symbols to represent numbers. Newer address types, bech32 addresses, instead use base32 which uses 32 different symbols to represent numbers. Aaron and Sjors discuss some of the benefits of using Bitcoin addresses in general. and bech32 addresses in specific. In addition, Sjors explains that the first version of bech32 addresses included a (relatively harmless) bug, and how a newer standard for bech32 addresses has fixed this bug.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost are once again joined by Ruben Somsen. This time, they discuss one of Ruben’s own proposals, called Softchains. Softchains are a type of two-way peg sidechains that utilize a new type of consensus mechanism: proof-of-work fraud proofs (or as Sjors prefers to call them, proof-of-work fraud indicators). Using this consensus mechanism, users don’t validate the content of each block, but instead only check the proof of work header, like Simplified Payment Verification (SPV) clients do. But using proof-of-work fraud proofs, users do validate the entire content of blocks any time a blockchain fork occurs. This offers a security model in between full node security and SPV security. Ruben explains that by using proof-of-work fraud proofs for sidechains to create Softchains, Bitcoin full nodes could validate entire sidechains at minimal cost. This new model might be useful for certain types of sidechains, most notably “block size increase” sidechains that do nothing fancy but do offer more transaction capacity. Aaron, Sjors and Ruben also discuss some of the downsides of the Softchain model.