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 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. Jameson Lopp’s blog posts: https://blog.lopp.net/bitcoin-core-performance-evolution/ https://blog.lopp.net/running-bitcoin-core-v0-7-and-earlier/  

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.

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.

Hosts Aaron van Wirdum and Sjors Provoost are back from their travel break for a brand new episode of Bitcoin, Explained! In this episode, they explain how Bitcoin’s peer-to-peer network is made more efficient and fast with Compact Blocks. Compact blocks are — as the name suggests — compact versions of Bitcoin blocks, that have been used by Bitcoin Core nodes since version 0.13. Compact Blocks contain the minimal amount of data required for Bitcoin nodes to reconstruct entire blocks. Most notably, Compact Blocks exclude most transaction data, to instead include short transaction identifiers. Bitcoin nodes can use these short identifiers to figure out which transactions from their mempools should be included in the blocks. Aaron and Sjors explain how and why Compact Blocks benefit the Bitcoin network, and specifically how they help counter mining centralization. The hosts also cover some edge cases that can result from the use of Compact Blocks — like the possibility that different valid transactions can have an identical identifier — and how Bitcoin nodes handle such occurrences.   Finally, Sjors briefly touches on some of the ongoing improvements that have been added to the Compact Blocks protocol since it was first introduced.

In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss a recent thread on the Bitcoin development mailing list, titled “Death to the Mempool, Long Live the Mempool”.   In the thread, Blockstream engineer Lisa “niftynei” Neigut proposes to get rid of the memory pool (mempool): the collection of unconfirmed transactions that Bitcoin nodes use to share transactions over the network, and that Bitcoin miners use to create new blocks from. She argues that the Bitcoin system could be drastically simplified if users instead just send their transactions directly to miners (or mining pools). In the episode, Aaron and Sjors explain how this would work, and why this is not as simple as it may sound. Based on the responses in the thread, they go over the reasons why getting rid of the mempool is in fact not a very good solution for a system like Bitcoin. Specifically, they discuss the implications on mining privacy and decentralization, while also exploring some other tradeoffs that would need to be made in order to make the Bitcoin system work without a mempool.   Finally, Sjors considers an idea that Aaron doesn’t understand.   --------------------------------------------- Bitcoin Magazine is back in print! Get Bitcoin Magazine shipped directly to your front door! Get 21% off with promo code: MAG21 https://store.bitcoinmagazine.com/discount/MAG21?redirect=%2Fproducts%2Fbitcoin-magazine-annual-subscription "The Deep Dive" delivers the latest Bitcoin on-chain market intelligence directly to your inbox! Check it out for free here! deepdivebtc.substack.com/welcome Bitcoin 2022 will be the biggest Bitcoin conference ever! Miami, FL from April 6–9, 2022 Get 15% off tickets with promo code: MAG21 https://b.tc/conference/

Bitcoin was under attack! It’s the story the mainstream media won’t tell you!   Hosts Aaron van Wirdum and Sjors Provoost finally met in Utrecht again to record Bitcoin, Explained. In this episode, they discuss a recent attack on the Bitcoin network, where some nodes were flooding peers with fake IP-addresses.   As previously discussed in episode 13, Bitcoin nodes connect to peers on the network through IP-addresses, which they learn from their existing peers. Nodes on the network essentially share the IP-addresses of other nodes.   Recently, however, some Bitcoin nodes shared large amounts of IP-addresses that weren’t associated with real Bitcoin nodes at all. While this attack did not do very much damage, it did waste resources from nodes on the network. On top of that, Aaron and Sjors explain, the attack could offer the attacker insight into Bitcoin’s network topology by analyzing how the fake IP-addresses spread through the network.   Finally, Aaron and Sjors discuss how the attack was solved by rate limiting the amount of IP-addresses than any node will allow its peers to be shared. Further, they consider how in free and open source software development, fixing problems is not always as straightforward as it may seem… --------------------------------------------- Bitcoin Magazine is back in print! Get Bitcoin Magazine shipped directly to your front door! Get 21% off with promo code: MAG21 https://store.bitcoinmagazine.com/discount/MAG21?redirect=%2Fproducts%2Fbitcoin-magazine-annual-subscription   "The Deep Dive" delivers the latest Bitcoin on-chain market intelligence directly to your inbox! Check it out for free here! deepdivebtc.substack.com/welcome   Bitcoin 2022 will be the biggest Bitcoin conference ever! Miami, FL from April 6–9, 2022 Get 15% off tickets with promo code: MAG21 https://b.tc/conference/

In this episode of “Bitcoin Explained,” host Sjors Provoost and guest Christian Decker discussed SIGHASH_ANYPREVOUT, a proposed new sighash flag that would enable a cleaner version of the Lightning Network and other Layer 2 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. --------------------------------------------- Bitcoin Magazine is back in print! Get Bitcoin Magazine shipped directly to your front door! Get 21% off with promo code: MAG21 https://store.bitcoinmagazine.com/discount/MAG21?redirect=%2Fproducts%2Fbitcoin-magazine-annual-subscription   "The Deep Dive" delivers the latest Bitcoin on-chain market intelligence directly to your inbox! Get 1 Month free with promo code: PODCAST https://deepdivebtc.substack.com/01e06e79   Bitcoin 2022 will be the biggest Bitcoin conference ever! Miami, FL from April 6–9, 2022 Get 15% off tickets with promo code: MAG21 https://b.tc/conference/ Decker and Provoost explained 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 the context of Eltoo, a proposed Layer 2 protocol that would enable a new version of the Lightning Network. In place of how 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, Decker and Provoost explained how SIGHASH_ANYPREVOUT would do away with this requirement.

In this episode of Bitcoin Explained, (formerly known as The Van Wirdum Sjorsnado) host Sjors Provoost is joined by Rene Pickhardt to discuss Rene’s paper “Optimally Reliable & Cheap Payment Flows on the Lightning Network”. Rene has spent the last two years researching the reliability of the lightning network, and the reliability of the payment process. They discuss the design principles of the lightning network, the difficulties with routing payments on lightning, probing channel balances, and much more.   Rene's Paper: https://arxiv.org/abs/2107.05322   --------------------------------------------- Bitcoin Magazine is back in print! Get Bitcoin Magazine shipped directly to your front door! Get 21% off with promo code: MAG21 https://store.bitcoinmagazine.com/discount/MAG21?redirect=%2Fproducts%2Fbitcoin-magazine-annual-subscription "The Deep Dive" delivers the latest Bitcoin on-chain market intelligence directly to your inbox! Get 1 Month free with promo code: PODCAST https://deepdivebtc.substack.com/01e06e79 Bitcoin 2022 will be the biggest Bitcoin conference ever! Miami, FL from April 6–9, 2022 Get 15% off tickets with promo code: MAG21 https://b.tc/conference/