Bitcoin, Explained — The Technical Side of Bitcoin

In this episode of Bitcoin, Explained, Aaron and Sjors explain Inscriptions, a new method to upload arbitrary data onto the Bitcoin blockchain.

Episode Sponsor: https://voltage.cloud/

Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425

In this episode of Bitcoin, Explained, Aaron and Sjors discuss the different types of timelocks available on Bitcoin (and what can go wrong when used incorrectly).

Episode Sponsor: https://voltage.cloud/

Sjors New Book: Bitcoin: A Work In Progress

Follow us on Twitter:

https://twitter.com/bitcoinmagazine

https://twitter.com/videobitcoin

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.

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

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:

THIS EPISODE’S SPONSORS:

Voltage

Bitcoin Magazine: Use promocode: BMLIVE for 10% off everything in our store!

Bitcoin Magazine Pro

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.

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.

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.

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.

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.

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.