Bitcoin Explained - The Technical Side of Bitcoin

In this episode of Bitcoin, Explained, Aaron and Sjors discuss two more electronic cash projects that predate Bitcoin: Wei Dai’s b-money and Hal Finney’s RPOW. As detailed in Aaron’s new book, The Genesis Book, these systems introduced design elements that were later utilized by Satoshi Nakamoto. Aaron and Sjors explain what these elements are, and how the inspired Bitcoin’s design. To buy Aaron’s new book, visit www.thegenesisbook.com. Mentioned: B-money (archive link): https://web.archive.org/web/20050211031649/http://www.eskimo.com/~weidai/bmoney.txt RPOW (archive link): https://nakamotoinstitute.org/finney/rpow/index.html === This episode’s sponsor: ⁠CoinKite⁠, maker of the ColdCard Aaron's Twitter: ⁠@AaronvanW⁠ Aaron’s Nostr: npub1art8cs66ffvnqns5zs5qa9fwlctmusj5lj38j94lv0ulw0j54wjqhpm0w5 Sjors’ Twitter: ⁠@provoost⁠ Sjors’ Nostr: npub1s6z7hmmx2vud66f3utxd70qem8cwtggx0jgc7gh8pqwz2k8cltuqrdwk4c If you’d like to sponsor the show, please email info at bitcoinexplainedpodcast.com ⁠https://bitcoinexplainedpodcast.com/

In this episode of Bitcoin, Explained, Aaron and Sjors discuss the so-called “block 1,983,702 problem”. They explain how a bug in early Bitcoin implementations could in rare cases cause a loss of funds, or in a worst-case scenario even lead to consensus failures, while they also explain how BIP 30 and BIP 34 solved this problem. As it turns out, however, BIP 34 introduced a new problem, that could become an issue about twenty years from now… === This episode’s sponsor: CoinKite, maker of the ColdCard Aaron's Twitter: @AaronvanW Aaron’s Nostr: npub1art8cs66ffvnqns5zs5qa9fwlctmusj5lj38j94lv0ulw0j54wjqhpm0w5 Sjors’ Twitter: @provoost Sjors’ Nostr: npub1s6z7hmmx2vud66f3utxd70qem8cwtggx0jgc7gh8pqwz2k8cltuqrdwk4c If you’d like to sponsor the show, please email info at bitcoinexplainedpodcast.com https://bitcoinexplainedpodcast.com/

In this episode of Bitcoin, Explained, Aaron and Sjors explain what new features are included in the upcoming Bitcoin Core 0.26 release. They also briefly discuss recent developments concerning the transaction inclusion policy of mining pool F2Pool, which appears to have been compliant with the OFAC sanctions list. Link to testing guide: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/26.0-Release-Candidate-Testing-Guide

In this episode, Aaron (@AaronvanW) and Sjors (@provoost) discuss a vulnerability in Libbitcoin dubbed “Milk Sad”, which allowed people to generate private key seeds with such weak entropy that their private keys could be brute forced and their coins stolen. Aaron and Sjors examine how this vulnerability (could have) ended up in Libbitcoin as well as in Andreas Antonopoulos’ book Mastering Bitcoin, to what extent it should be considered a bug, and more.For more information on Milk Sad, see: https://milksad.info/Libbitcoin lead developer Eric Voskuil on Milk Sad: https://youtu.be/3uwl5xDdc7c Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 THIS EPISODE’S SPONSORS: ⁠Voltage Cloud⁠ ⁠Bitcoin 2024 Nashville⁠ ⁠Bitcoin Magazine⁠ ⁠Bitcoin Amsterdam⁠ Lower your time preference and lock-in your BITCOIN 2024 conference tickets today! Use the code BMLIVE for a 10% Discount! - https://b.tc/conference/2024

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. THIS EPISODE’S SPONSORS: Voltage - https://voltage.cloud/ Bitcoin 2023 Miami - https://b.tc/conference/ Bitcoin Magazine - https://store.bitcoinmagazine.com/ Bitcoin Magazine Pro - https://bitcoinmagazine.com/tags/bitcoin-magazine-pro Lower your time preference and lock-in your BITCOIN 2023 conference tickets today! Use the code BMLIVE for a 10% Discount! https://b.tc/conference/2023 Use promocode: BMLIVE for 10% off everything in our store! https://store.bitcoinmagazine.com/

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. Lower your time preference and lock-in your BITCOIN 2023 conference tickets today! Use the code BMLIVE for a 10% Discount! https://b.tc/conference/2023 Use promocode: BMLIVE for 10% off everything in our store! https://store.bitcoinmagazine.com/

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 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/