20:52

Ep. 70 Dec 30, 2022

Episode 70: Bitcoin Core v24 Bug

Aaron and Sjors explain how a wallet bug crept into the Bitcoin Core 24.0 release, and why there is now a Bitcoin Core version 24.0.1 available. Chapters 00:00:00 Introduction and Bitcoin: A Work in Progress 00:02:44 Bitcoin Core 24.0 and the 24.0.1 release 00:05:53 Listener boosts and streaming sats 00:06:58 RBF: new transactions versus replacements 00:10:59 The coin selection bug and excessive fees 00:14:40 How refactoring introduced the bug 00:17:03 Why the bug survived only in the release branch 00:18:47 Bug fixes, maintenance releases and backporting Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Follow us on Twitter: - https://twitter.com/bitcoinmagazine - https://twitter.com/videobitcoin

37:18

Ep. 69 Dec 2, 2022

Episode 69: The Tornado Cash Trial

Aaron and Sjors explain what happened in the pro forma hearing concerning the trial against Alexy P., one of the developers behind the Ethereum-based Tornado Cash mixer. While this means that this episode dives more into the domain of Ethereum smart contracts and Dutch law, Aaron and Sjors do discuss the ongoing case from a Bitcoin perspective. Background: Coin Center: How does Tornado Cash work Coindesk: 3 Things We Learned at Tornado Cash Dev Trial Chapters 00:00:00 Streaming sats and listener boosts 00:03:36 The Dutch hearing and detention 00:06:46 How Tornado Cash mixes ether 00:08:30 Gas fees and privacy-preserving relayers 00:10:54 TORN tokens and relayer incentives 00:13:57 DAO governance and control of the interface 00:21:21 Open-source software or a centralized business? 00:24:55 Money-laundering allegations and legal tests 00:27:33 Compliance tools and their limitations 00:32:01 Implications for Bitcoin privacy tools THIS EPISODE’S SPONSORS: Voltage Bitcoin Magazine: Use promocode: BMLIVE for 10% off everything in our store! Bitcoin Magazine Pro

39:57

Ep. 68 Nov 18, 2022

Episode 68: RBF In Bitcoin Core 24.0

Aaron and Sjors revisit replace-by-fee (RBF). As they mentioned in episode 65, the upcoming Bitcoin Core release — Bitcoin Core 24.0 — includes the option to switch on “full RBF”, but this has caused some commotion in the Bitcoin community since the recording of that episode. Aaron and Sjors explain what this commotion has been about, and they highlight some of the new arguments for and against (full) RBF. RBF has been the topic of a previous Bitcoin, Explained episode: episode 26. In this new episode, therefore, Aaron and Sjors don’t explain in-depth on what RBF is, exactly, or how it works. They do however very briefly summarize its most important aspects. Aaron and Sjors then go on to explain why Bitcoin Core developers originally decided to include this feature, and they discuss some of the arguments for and against (full) RBF that came up at the time and since then. These include the effect of RBF on “pinning attacks” (a type of attack that is especially relevant for the Lightning Network and other Layer Two protocols), the relative safety of accepting unconfirmed transactions today, privacy-related arguments concerning the “opt-in” flag that RBF transactions currently use, the detrimental effects of monitoring the network for potential double spends, and more. Aaron and Sjors also discuss the pros and cons of including RBF as an optional feature and thus letting node operators decide for themselves how their node deals with conflicting unconfirmed transactions. Sjors outlines why, in some cases, giving users more options could have detrimental effects on the health of the Bitcoin network, and considers whether the option to include the RBF option is such a case. Finally, Aaron and Sjors briefly discuss an initiative by full RBF advocate Peter Todd to incentivize miners to apply full RBF logic to their transaction selection. Chapters 00:00:00 Full RBF and the Bitcoin Core 24.0 delay 00:06:01 Pinning attacks and the case for full RBF 00:11:25 Lightning complexity and miner incentives 00:15:59 Muun Wallet and zero-confirmation payments 00:18:53 Merchants and the risks of accepting zero-conf 00:21:46 Privacy, stuck transactions and merchant trade-offs 00:26:19 Removing a merged feature: release process and debate 00:28:39 Node options, diverging mempools and mining risks 00:36:36 Peter Todd’s full RBF miner bounty

48:08

Ep. 67 Nov 7, 2022

Episode 67: Insights From the 4th Largest Lightning Network Node

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost speak with Sam Wouters, a research analyst at River Financial. River operates the fourth largest node on the Lightning network, and Sam recently published a report detailing unique insights from this Lightning node. At the start of the episode, Sjors first gives a brief update on the bug that brought down LND nodes, discussed in episode 66. He confirms that his assessment of the cause was correct, and explains that a very similar bug has brought down LND once more since recording of the last episode. Aaron and Sjors then go on to ask Sam about the contents of his report, with a focus on three subsections of the report in particular. First, Aaron, Sjors and Sam discuss the current status of fees and liquidity. Sam explains that large Lightning nodes can earn a “return on investment” of several percentages per year by routing payments over the network, but that this does require active channel maintenance to manage liquidity. Second, Aaron, Sjors and Sam discuss why some Lightning payments fail. Sam explains that the success rate of Lightning payments is very high compared to just a few years ago, but that there are two main reasons why payments sometimes do still fail: payment timeouts, and a lack of available routes. The trio speculates why this might be the case. Lastly, Sam outlines some of the challenges and concerns related to running Lightning infrastructure for businesses. Chapters 00:00:00 Sam Wouters and River Financial 00:01:29 Another LND bug and responsible disclosure 00:09:44 River’s Lightning node report 00:14:05 Routing fees and returns 00:15:54 Managing liquidity and vetting channels 00:21:24 On-chain fees and routing economics 00:26:19 Why Lightning payments fail 00:33:48 Probing and Lightning privacy 00:37:35 Payment sizes and reliability 00:41:11 Lightning infrastructure for businesses

31:56

Ep. 66 Oct 21, 2022

Episode 66: The BTCD Bug That Brought Down LND Nodes

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss a recent bug in the btcd Bitcoin implementation that affected a large part of the Lightning network, as it disconnected lnd Lightning nodes from the Bitcoin blockchain. In the episode, Aaron and Sjors explain that a developer going by the name Burak on Twitter created a 998-of-999 multisig transaction by leveraging Taproot. Although this was a valid transaction, btcd and lnd nodes rejected it, and therefore rejected the block that included the transaction and all blocks that came after it. Specifically, Sjors explains, btcd rejected the transaction because it has a maximum limit on how much witness data a Segwit transaction can include. Although other Bitcoin implementations do enforce this limit on Segwit version 0 transactions, Segwit version 1 (that is, Taproot) transactions have no such limit. Still, it is a bit unclear why this bug in btcd seemingly also affected many lnd Lightning nodes which use Bitcoin Core rather than btcd to validate blocks. In the second half of the episode, Sjors speculates how the two may be connected. Finally, Aaron and Sjors explain how the Lightning Network is affected when Lightning nodes reject the Bitcoin blockchain. Chapters 00:00:00 Bitcoin Amsterdam and opening updates 00:01:27 The LND outage and Burak’s transaction 00:04:26 Taproot multisig and witness size limits 00:11:49 The btcd validation bug 00:15:14 How stalled blocks affect Lightning channels 00:17:11 Why LND nodes using Bitcoin Core were affected 00:22:42 Fork Monitor and a bug predating Taproot 00:24:43 User risks: channel timeouts and cheating 00:29:49 Routing failures and open questions

39:07

Ep. 65 Oct 7, 2022

Episode 65: Bitcoin Core 24.0

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss the upcoming Bitcoin Core major release, Bitcoin Core 24.0. The Bitcoin Core project produces a new major release of its software roughly every six months. The 24th major release is currently in its release candidate phase, which means that it is being tested and could technically be released any day now (though this phase will probably last a few more weeks). In the episode, Aaron and Sjors discuss seven of the most notable changes included in Bitcoin Core 24.0. This includes a change to how nodes download blocks when they sync with the network. While previous Bitcoin Core versions already started by downloading only block headers to make sure that the blocks they download have sufficient proof of work on them, Bitcoin Core 24.0 nodes will initially not store these block headers in order to prevent a certain type of resource exhaustion attack. Aaron and Sjors explain that this should eventually also allow for the removal of any checkpoints in the Bitcoin Core codebase. They go on to explain that Bitcoin Core 24.0 also includes an added option for users to apply full replace-by-fee (RBF) logic. Where Bitcoin Core nodes so far would apply the “first seen” rule, which meant that conflicting transactions wouldn’t be accepted in the node’s memory pool (mempool) and forwarded to peers, Bitcoin Core 24.0 users can choose to make their nodes accept and forward conflicting transactions if they include a higher fee than (the) earlier transaction(s) they conflict with. Further upgrades discussed by Aaron and Sjors include a tool to migrate legacy wallets to descriptor wallets, initial miniscript support, default use of RBF when creating transactions, an improved UTXO selection algorithm which randomizes change output amounts for extra privacy, and a new “send all” function to spend a particular (set of) UTXO(s) in full. Chapters 00:00:00 Introduction and Bitcoin Amsterdam 00:01:57 Bitcoin Core 24.0 and release candidates 00:05:39 Header synchronization and resource exhaustion defenses 00:15:45 Optional full replace-by-fee 00:21:40 Migrating legacy wallets to descriptor wallets 00:25:05 Initial Miniscript support and limitations 00:29:29 Opt-in RBF by default in the wallet RPC 00:31:35 Randomized change amounts for privacy 00:36:22 The sendall RPC and wallet spending intent

28:29

Ep. 64 Sep 19, 2022

Episode 64: HD Wallets, Mnemonic codes and SeedQR

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss Hierarchical Deterministic (HD) Wallets, mnemonic codes, and — especially — the new SeedQR format which allows users to store their mnemonic codes as QR codes. Aaron and Sjors start the episode by recapping what HD Wallets (also known as private key seeds) are, and why they are preferred over regular private key backups. Next, they briefly explain why mnemonic codes (also known as seed phrases) are a popular solution for encoding and storing private key seeds. The Bitcoin, Explained hosts then go on to discuss SeedQR. SeedQR is a new format that allows Bitcoin users to encode and store their mnemonic code as a QR code. This means that mnemonic codes can be stored in a computer-readable format; any compatible device (like a hardware wallet with a camera) should be able to scan the QR code, and import all associated private keys. This could be useful for backups. but it could also be used so that wallets (including hardware wallets, but also mobile or desktop wallets) no longer have to store private keys at all. The QR code could be scanned when the wallet is used to send a transaction, after which the private keys could be forgotten by the device altogether. (SeedSigner is an open source, do-it-yourself hardware wallet that does exactly this.) Finally, Sjors goes over some of the intricacies of formatting a seed phrase to fit in a compact QR code, and some of the efficiency gains SeedQR uses to accomplish this. Chapters 00:00:00 Bitcoin Amsterdam announcement 00:01:41 SeedQR, steel backups and SeedSigner 00:04:28 Why early Bitcoin wallets needed repeated backups 00:07:01 BIP 32: HD wallets and a single seed 00:08:13 BIP 39: mnemonic words and language compatibility 00:12:04 12 versus 24 words: security and backup trade-offs 00:15:18 SeedQR for backups and wallets without stored keys 00:18:30 Drawing SeedQR by hand: size and error correction 00:23:08 Compact SeedQR encoding and scanner compatibility 00:25:14 Human-readable backups and better error correction

37:20

Ep. 63 Sep 2, 2022

Episode 63: The Bitcoin Core development process

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss the Bitcoin Core development process, and more specifically, the different roles that are involved in this process. At the start of the episode, Aaron and Sjors explain what Bitcoin Core is, both in a practical sense as well as in a more definitional sense, and they touch on some slightly different ideas about this as well. Aaron and Sjors then go on to explain the roles of three distinct types of Bitcoin Core contributors: “regular” Bitcoin Core contributors, Bitcoin Core maintainers, and the Bitcoin Core lead maintainer. Since there are no barriers to entry, anyone can become a Bitcoin Core contributor, Aaron and Sjors point out: anyone can start contributing to the Bitcoin Core project by offering code, review of code, or perhaps other types of contributions like text translations. Bitcoin Core maintainers, then, are Bitcoin Core contributors who can merge new code into the Bitcoin Core codebase. Aaron and Sjors explain what this means exactly, and how someone can become a Bitcoin maintainer. Finally, Aaron and Sjors go over some of the typical tasks of the Bitcoin Core lead maintainer, which includes managing the release process, adding and removing (other) Bitcoin Core maintainers to the project, and updating the bitcoincore.org website. They also discuss which of these tasks are in fact still done by the Bitcoin Core lead maintainer, however, and which tasks have over the years become more distributed. Chapters 00:00:00 Bitcoin Amsterdam listener discount 00:01:41 Wladimir van der Laan steps down 00:03:02 What defines Bitcoin Core? 00:11:51 Contributing to Bitcoin Core 00:12:58 Maintainers, pull requests and code review 00:16:56 Becoming a maintainer and verifying signed commits 00:20:28 The lead maintainer and release process 00:24:51 Reproducible builds, release signatures and coordination 00:30:11 GitHub control and a future without a lead maintainer

34:52

Ep. 62 Aug 12, 2022

Episode 62: Hash functions

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. Chapters 00:00:00 Hash functions and their essential properties 00:04:53 Broken hashes and collision attacks 00:09:17 Password hashing, rainbow tables and salts 00:12:26 How hash algorithms scramble bits 00:15:30 SHA-256, hash history and trust in their design 00:23:11 Block hashes and linking the blockchain 00:25:46 Proof of work and mining 00:27:22 Transaction IDs, signatures and SegWit 00:29:07 Taproot, addresses, randomness and key derivation

25:21

Ep. 61 Jul 15, 2022

Episode 61: OP RETURN Wars

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/ Chapters 00:00:00 The OP_RETURN wars of 2014 00:01:31 How OP_RETURN works 00:04:39 Blockchain data and UTXO set costs 00:10:31 The 40-byte limit and Counterparty 00:17:09 80 bytes of data versus an 83-byte script 00:18:07 Fee markets, node costs and privacy 00:22:04 Ethereum and Bitcoin’s development culture 00:23:40 VeriBlock and competition for block space

32:15

Ep. 60 Jul 1, 2022

Episode 60: Reusing addresses and the Hertzbleed attack

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: ** Chapters 00:00:00 Bitcoin Amsterdam and address reuse 00:01:31 What reusing a Bitcoin address means 00:05:04 Privacy risks: savings, income and exchange deposits 00:08:29 Address blacklisting and censorship resistance 00:09:08 Security risks from reused signature nonces 00:13:57 Quantum computers and exposed public keys 00:16:42 Preparing Bitcoin for quantum computing 00:21:54 Hertzbleed and timing side-channel attacks 00:29:00 Practical risks and Bitcoin address terminology

40:00

Ep. 59 Jun 20, 2022

Episode 59: Has Bitcoin Ever Hard Forked?

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. Jameson Lopp’s blog post Chapters 00:00:00 Introduction and finding Bitcoin peers over Tor 00:03:21 Hard forks, soft forks and Lopp’s definitions 00:12:13 Untriggered changes: longest chain versus most work 00:15:27 OP_VER and software-dependent consensus 00:18:06 Separating scriptSig and scriptPubKey evaluation 00:19:00 The unused Bitcoin Core inflation bug 00:20:18 Burying soft forks with BIP90 00:22:07 The Berkeley DB bug and the 2013 chain split 00:28:36 Adding OP_NOP: an explicit hard fork 00:34:39 Future hard forks, emergency fixes and consensus

45:21

Ep. 58 Jun 10, 2022

Episode 58: Silent Payments

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. Chapters 00:00:00 Silent payments and address reuse 00:04:35 Shared secrets and recipient-only spending 00:12:05 Detecting payments by scanning transactions 00:16:14 Faster scanning and wallet recovery 00:20:03 Comparing silent payments with stealth addresses 00:24:18 BIP47 reusable payment codes and privacy trade-offs 00:28:24 Interactive alternatives and static payment identifiers 00:33:57 Full nodes, light clients and the working prototype 00:40:22 CoinJoin compatibility and input aggregation

42:47

Ep. 57 May 6, 2022

Episode 57: URSFs (User Rejected Soft Forks)

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. Chapters 00:00:00 Bitcoin: A Work in Progress 00:01:26 How user rejected soft forks work 00:09:01 Miner signaling and the miner veto 00:11:01 Flag day activation and reorg risks 00:16:12 Mandatory signaling with BIP 148 00:18:59 URSFs as an opt-out from UASFs 00:25:05 Futures markets before a chain split 00:27:38 Market efficiency and manipulation risks 00:33:47 Rough consensus and user vetoes 00:38:39 Soft forks without signaling

33:59

Ep. 56 Apr 25, 2022

Episode 56: Bitcoin Core 23.0

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. Chapters 00:00:00 Introduction and listener topic requests 00:02:07 Bitcoin Core 23.0 and release candidate testing 00:04:26 Connecting to peers beyond port 8333 00:10:47 CJDNS network support 00:12:41 Fee estimation and replace-by-fee transactions 00:17:28 USDT tracepoints for node monitoring 00:22:05 Finding typos in Bech32 addresses 00:24:23 Taproot wallet support 00:26:41 Persistent coin freezing and privacy 00:29:37 Fixing a Windows compiler bug

35:23

Ep. 55 Mar 25, 2022

Episode 55: Syncing Old Bitcoin nodes

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 the episode, Aaron and Sjors outline the performance improvements of Bitcoin Core clients over time, as analyzed most recently in two blog posts by Lopp. They first explain why some very old Bitcoin clients have trouble syncing to the current state of the blockchain at all, pointing out some bugs in this early software, as well as issues relating to dependencies and the challenge of using such old clients today. Sjors then goes on to sum up some of the most important performance improvements that have been included in new Bitcoin Core releases over time. Chapters 00:00:00 Syncing old Bitcoin nodes: the experiments 00:02:42 Why backward compatibility matters 00:05:34 Early node failures and software dependencies 00:09:30 BerkeleyDB limits and the 2013 chain split 00:14:50 OpenSSL changes and rebuilding old clients 00:20:36 Initial sync times and blockchain growth 00:25:13 How Bitcoin Core became faster 00:32:44 SegWit validation and the limits of old nodes

35:21

Ep. 54 Feb 25, 2022

Episode 54: Burying Soft Forks

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). Chapters 00:00:00 Burying Taproot and soft-fork rules 00:06:17 Applying Taproot from genesis with exceptions 00:09:04 Code cleanup and simpler tests 00:13:46 Deep reorganizations and chain-split risk 00:19:28 Reorg thresholds and checkpoint comparisons 00:23:27 Signaling, social consensus and activation time 00:28:54 Consensus change or implementation shortcut?

50:18

Ep. 53 Feb 11, 2022

Episode 53: Discreet Log Contracts

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. Chapters 00:00:00 Discreet Log Contracts and oracle trust 00:05:08 A World Cup bet using multisig 00:09:34 Reality Keys: publishing outcome keys 00:14:28 The original DLC payment-channel design 00:20:13 Turning oracle signatures into spending keys 00:26:00 The Schnorr signature equation 00:32:18 Streamlining DLCs with adaptor signatures 00:39:18 Numeric outcomes and binary oracle signatures 00:46:25 Reducing setup work with OP_CTV 00:47:38 DLC implementations and experiments

43:09

Ep. 52 Jan 14, 2022

Episode 52: Federated Ecash

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost are once again joined by resident sidechain and Layer Two expert Ruben Somsen, this time to discuss Federated Ecash, a project that has since October 2021 been sponsored by Bitcoin infrastructure company Blockstream. In the episode, Aaron, Sjors and Ruben discuss the history and design of Ecash, a pioneering digital cash project developed by cryptographer David Chaum and his startup Digicash in the early 1990s. The trio explains how the Ecash system allowed customers of regular banks to make private transactions over the internet. This latest iteration of Ecash, Federated Ecash, takes the original concept, but applies it to be utilized by custodial (or shared custodial) Bitcoin and Lightning wallets. In short, a Federated Ecash service would accept bitcoin deposits, and exchange them for bitcoin-denominated Ecash tokens. These tokens can be send to other users, and ultimately redeemed for the deposited bitcoin. These bitcoin would, in the mean time, be locked up in a multisig address shared between a set of custodians. Concluding the episode, Aaron, Sjors and Ruben go over a short list of ideal properties for a digital cash system, and asses how Bitcoin, Ecash, and the combination of the two embed these properties. Chapters 00:00:00 Federated ecash with Ruben Somsen 00:03:33 David Chaum, DigiCash and digital cash 00:07:09 Blind signatures and private payments 00:12:44 Bitcoin-backed federations and shared custody 00:16:06 Improving custodial wallets with ecash 00:18:24 Connecting federations through Lightning 00:26:02 Trust, reserves and hidden inflation 00:28:49 Denominations, timing and network privacy 00:34:02 The ideal properties of digital cash