Bitcoin, Explained — The Technical Side of Bitcoin

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost go back to basics. They explain one of the most fundamental building blocks in all of Bitcoin: hash functions.

To start the episode off, Aaron and Sjors explain that hash functions are a type of mathematical one-way functions. That means that they can easily convert one piece of data into another piece of data, a hash, but anyone who knows only this hash can not convert it back to the original data. Additionally, a hash is supposed to be unique: no two (different) pieces of data should result in the same hash. If either of these things is no longer true, a hash function is considered to be broken.

Then, Aaron and Sjors go on to explain in a little bit more detail how hash functions actually work. They discuss some aspects of the history and evolution of different hash functions, they mention some hash functions that have indeed been broken over time, and they pinpoint which hash functions are used in Bitcoin.

Finally, Aaron and Sjors explain how hash functions are used in Bitcoin, exactly. This includes almost every aspect of the Bitcoin system, they point out, ranging from transactions (in multiple ways) and blocks, to addresses and the proof of work mechanism, as well as in relatively new upgrades like Taproot, and hash functions are even used to create some randomness needed to establish connections on the peer-to-peer network.

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss OP_RETURN and what some have called the “OP_RETURN wars”. More specifically, they discuss a blog post by BitMEX research titled: “The OP_Return Wars of 2014 – Dapps Vs Bitcoin Transactions”.

Aaron and Sjors start off by explaining that OP_RETURN is an op code (a piece of code for Bitcoin transactions) that will render invalid any transaction that includes it in an input. This means that outputs that include OP_RETURN are unspendeable, which in turn means that Bitcoin nodes can safely remove such UTXOs from their UTXO set, which safes on storage.

Early in Bitcoin’s years, people started using Bitcoin for more than just transactions. As one example given by Sjors, someone uploaded the entire Bitcoin white paper onto the blockchain. The BitMEX blog meanwhile explains that Layer Two protocols like Counterparty were rolling out decentralized applications on the blockchain. This type of non-transaction data was initially embedded in multisig transactions, but this meant that all Bitcoin nodes had to download, process and store this data forever, which comes at a cost.

To mitigate this problem, Aaron and Sjors explain, Bitcoin developers in 2014 agreed to let nodes process and forward transactions with OP_RETURN outputs. These transactions would be better for uploading data, since their outputs can be removed form the UTXO set.

The “OP_RETURN wars” refer to a debate between Bitcoin developers and (most notably) Counterparty developers over the maximum size of such transactions. Sjors explains why the maximum of 40 bytes was initially choses, why this was later increased to 80 bytes, and how these considerations have changed over time.

BitMEX’ blog post: https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/

Sjors’ book mentioned in the episode: https://www.btcwip.com/

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss reusing Bitcoin addresses. More specifically, they explain why reusing Bitcoin addresses is a bad idea.

Reusing Bitcoin addresses is a bad idea for roughly three reasons. The first two of these are that it harms privacy and impedes on the censorship resistance of Bitcoin. In the episode, Aaron and Sjors go over a couple examples of how such a loss of privacy and censorship resistance can negatively affect Bitcoin users.

The third reason that reusing Bitcoin addresses is a bad idea, is that it opens up the possibility of some niche attacks. In certain cases, attackers could extract private keys from signatures after coins are first spent from an address — though this does require that a wallet implemented the signing algorithm wrongly in the first place. There are also some scenarios where quantum computers could in the future extract private keys from signatures if addresses are reused.

Another type of niche attack is a timing sidechannel attack, such as the recently disclosed Hertzbleed Attack. Sjors explains that attackers can potentially derive a private key from a wallet by closely monitoring how the computer that hosts the wallet behaves when signing a transaction. This attack is more plausible if addresses are reused.

Address reuse wiki: https://en.bitcoin.it/wiki/Address_reuse#Security Hertzbleed attack: https://www.hertzbleed.com/

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss a recent blog post by James Lopp titled, “Has Bitcoin Ever Hard Forked”? Hard forks are generally defined as Bitcoin protocol upgrades that remove or loosen rules, making these types of upgrades backwards-incompatible. Aaron and Sjors explain, however, that Lopp in his blog post argues that this definition isn’t very precise and suggests the term should only apply if the rule change was actually utilized. In addition, hard forks can be categorized into explicit hard forks, where the rule change was an intentional hard fork, and implicit hard forks, where the rule change wasn’t originally intended to be a hard fork at all but turned out to be one anyways.

In the second half of the podcast, Aaron and Sjors break down the seven hard forks in Bitcoin’s history that Lopp was able to find, of which five were never utilized (and should therefore arguably not be considered hard forks at all), one was explicit, and one was implicit.

Finally, Aaron and Sjors briefly discuss (a) future hard fork(s) that need(s) to happen, and what kind of philosophy around deploying hard forks might make sense for Bitcoin.

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost welcome Ruben Somsen back on the show to talk about a recent proposal of his called “Silent Payments”. Silent Payments resemble earlier ideas like Stealth Addresses and Reusable Payment Codes, in that they allow users to publish a static “address”, while this is not the actual Bitcoin address they will be paid on. Instead, senders of a transaction can use this static address to generate new Bitcoin addresses for the recipient, for which the recipient — and only the recipient — can in turn generate the corresponding private keys. Like Stealth Addresses and Reusable Payment Codes, the benefit of Silent Payments is that addresses can be posted publicly without harming users’ privacy; snoops cannot link the publicly posted address to the actual Bitcoin addresses that the recipient is paid on. Meanwhile, unlike Stealth Addresses and Reusable Payment Codes, Silent Payments do not require any additional blockchain data— though this does come at a computational cost for the recipient. The podcast episode details all this in roughly two parts. In the first half of the episode, Ruben, Aaron and Sjors break down how Silent Payments work, and in the second half of the episode they discuss how Silent Payments compare to Stealth Addresses and Reusable Payment Codes, as well as some potential implementation issues.

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss URSFs, which stands for either User Rejected Soft Forks or User Resisted Soft Forks, depending on who you ask. URSFs are a recently introduced tool in Bitcoin’s upgrade mechanism toolkit.

In the first part of the episode, Aaron and Sjors explain that URSFs are best considered the mirror equivalent of UASFs (User Activated Soft Forks) with mandated signaling. Where UASFs will towards the end of a soft fork activation window reject blocks that don’t signal readiness for a soft fork, URSFs will reject blocks that do signal. If both UASF and URSF clients are deployed, they would in principle create a split in the blockchain.

In the second part of the episode, the duo outlines the various soft fork upgrade mechanisms, ranging from MASFs (Miner Activated Soft Forks), flag day activated UASFs and mandated signaling UASFs. Aaron then explains why he believes mandated signaling UASFs are his preferred method of deploying soft forks, and why he thinks URSFs should in the future be offered as an added option for users who prefer to reject the soft fork.

Finally, Sjors lays out the “rough consensus” guidelines as used in context of the Internet Engineering Taskforce (IETF), and how this applies to Bitcoin upgrades.

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss Bitcoin Core 23.0, the upcoming major release of Bitcoin’s de facto reference implementation. The duo highlights some of the most notable changes in this new software client, and they offer a bit of extra context about the release as well.

At the time of recording this episode, Bitcoin Core 23.0 was still going through the release candidate phase, where the software is tested for bugs; Aaron and Sjors start by explaining how this process works, exactly.

Then, throughout the episode, Aaron and Sjors highlight seven changes that are included in this new Bitcoin Core release: 1) the removal of the preference to connect with peers through port 8333, 2) the added support for CJDNS, 3) the inclusion of replace-by-fee transactions in the transaction fee estimation algorithm, 4) the inclusion of statically defined tracepoints, 5) a new tool to spot typos in bech32 addresses, 6) the addition of support for Taproot in the wallet, and 7) the new option to freeze certain UTXOs until some time in the future.

Finally, Aaron and Sjors discuss how a bug in a software compiler had initially resulted in a bug in an earlier version of this Bitcoin Core release for Windows, giving an interesting insight in the complications with upstream dependencies.

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss research done by CasaHODL co-founder and CTO Jameson Lopp as well as Sjors himself on syncing old Bitcoin nodes. Whenever a new Bitcoin node comes online, it must first sync with the rest of the Bitcoin network: it needs to download and verify the entire blockchain up until the most recent block in order to be up to date on the state of bitcoin ownership. This can take quite a while, however, and should take longer over time as the blockchain keeps growing. To offset this, and to improve user experience more generally, Bitcoin Core developers seek to improve performance of the Bitcoin Core code so that newer releases sync faster than their predecessors.

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost revisit the Taproot activation saga, this time to discuss burying of soft forks. Taproot, the last soft fork to have been deployed on the Bitcoin network, activated in late 2021. Now, Bitcoin Core developers are considering to “bury” the soft fork, which means that future Bitcoin Core releases will treat Taproot as if the rule change has been active since Bitcoin’s very beginning. (With the exception of one block mined in 2021 that breached the Taproot rules which have since been added to the protocol.) In the episode, Sjors explains what the benefits are of burying a soft fork, in particular pointing out how it helps developers when they review the Bitcoin Core codebase or when they perform tests on it. After that, Aaron and Sjors outline a potential edge case scenario where burying soft forks could, in a worst-case scenario, split the Bitcoin blockchain between upgraded and non-upgraded nodes. Bitcoin Core developers generally don’t consider this edge case — a very long block re-org — to be a realistic problem and/or believe that this would be such a big problem that a buried soft fork would be a minor concern comparatively. However, they explain, not everyone agrees with this assessment entirely…

Finally, Aaron and Sjors touch on issues like whether soft fork activation logic should itself be considered a soft fork, and whether soft fork burying logic should be considered a consensus change and/or require a Bitcoin Improvement Proposal (BIP).

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost are joined by resident sidechain and Layer Two expert Ruben Somsen again, this time to discuss Discreet Log Contracts (DLCs).

Discreet Log Contracts are a type of smart contracts for Bitcoin, first proposed by Lightning Network white paper coauthor Tadge Dryja. In essence, DLCs are a way to perform bets— but this means that they can ultimately be leveraged for all sorts of financial instruments, including futures markets, insurances and stablecoins.

At the start of the episode, Aaron, Sjors and Ruben discuss what can be considered a type of proto-DLC, namely a multi-signature setup for sports betting where two participants add a neutral third party (an “oracle”) that can resolve the bet one way or the other if needed. The trio explains, however, how this solution comes with a number of downsides, like the difficulty of scaling it.

From there, Aaron, Sjors and Ruben go on to explain how DLCs solved these problems using a setup that resembles payment channels as used on the Lightning Network. When structured like this, they explain, oracles merely need to publish a cryptographically signed message about the outcome of an event, which can be used by the winning participant of the bet to create a withdrawal transaction from the payment channel. Finally, Ruben explains how the original DLC concept could be streamlined by using adaptor signatures, a sort of “incomplete signatures” that can be made complete using the signed message from the oracle. With adaptor signatures, DLCs no longer require a separate withdrawal transaction, as the winner can claim funds from the payment channel directly.