In this episode of Bitcoin, Explained, Aaron (@AaronvanW) and Sjors (@provoost) explain why the witness discount was included in the Segregated Witness protocol upgrade from 2017, why this discount is 75%, and why this discount still makes sense in today’s world where Inscriptions benefit from it. Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 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, Aaron (@AaronvanW) and Sjors (@provoost) explain Partially Signed Bitcoin Transactions (PSBTs), discussing what problems they solve, how they work, and some of the ways they are used. In the last part of the episode, the hosts zoom in on one particular PSBT use case called Dutch Auctions, which Bitcoin Magazine recently used to sell ordinals. Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Don't miss out on the biggest Bitcoin event of the year! B23 in Miami is coming up fast, get your tickets now! 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

In this episode of Bitcoin, Explained, Aaron and Sjors discuss BIP 324, the proposal by Dhruv, Pieter Wuille and Tim Ruffing to add peer-to-peer (P2P) encryption to the Bitcoin protocol. They explain why this is needed, how it would work, and which problems it would, and wouldn’t solve. Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Don't miss out on the biggest Bitcoin event of the year! B23 in Miami is coming up fast, get your tickets now! 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

In this episode of Bitcoin, Explained, Aaron and Sjors explain Stamps, a new(?) protocol to upload images onto the Bitcoin blockchain, which end up in the UTXO set. To learn more about some of the concepts mentioned in this episode, also check out episode 15 (Utreexo), episode 61 (OP_RETURN), episode 72 (Inscriptions) and episode 75 (Multisig). Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Don't miss out on the biggest Bitcoin event of the year! B23 in Miami is coming up fast, get your tickets now! 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

In this episode of Bitcoin, Explained, Aaron and Sjors discuss multi-signature (multisig), and the various ways that Bitcoin enables multisig; from bare multisig, to P2SH, SegWit, Taproot, and finally Musig, as well as some potential future solutions. Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Don't miss out on the biggest Bitcoin event of the year! B23 in Miami is coming up fast, get your tickets now! 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

In this episode of Bitcoin, Explained, Aaron and Sjors explain pay-to-script-hash (P2SH), which allows bitcoin to be sent to and from the hash of a script. Besides (the current implementation of) P2SH itself, Aaron and Sjors also discuss some alternatives that were proposed around the time that P2SH was adopted in 2012. For further reading on the history of P2SH, also see "The Battle for P2SH: The Untold History of Bitcoin’s First War" Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Don't miss out on the biggest Bitcoin event of the year! B23 in Miami is coming up fast, get your tickets now! Lower your time preference and lock-in your BITCOIN 2023 conference tickets today! Use the code BMLIVE for a 10% Discount! 

In this episode of Bitcoin, Explained, Aaron and Sjors explain OP_VAULT, a proposed op code that would enable an elegant type of vaults through Bitcoin’s scripting language. For more information, also see: https://jameso.be/vaults.pdf https://github.com/bitcoin/bips/blob/c589490f98ba1b0c606d0e2030463f1fde54b786/bip-vaults.mediawiki === Episode Sponsor: https://voltage.cloud/ Sjors New Book: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Don't miss out on the biggest Bitcoin event of the year! B23 in Miami is coming up fast, get your tickets now! 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

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 Don't miss out on the biggest Bitcoin event of the year! B23 in Miami is coming up fast, get your tickets now! 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

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: https://www.amazon.com/Bitcoin-Technical-innovations-Sjors-Provoost/dp/9090360425 Lower your time preference and lock-in your Bitcoin 2023 conference tickets today!!! Use promo code BMLIVE to save 10% off your conference tickets today!!! https://b.tc/conference/bitcoin2023 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 Lower your time preference and lock-in your Bitcoin 2023 conference tickets today!!!  Use promo code BMLIVE to save 10% off your conference tickets today!!! https://b.tc/conference/bitcoin2023  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 Pertsev, 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. 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 revisit replace-by-fee (RBF). As they mentioned in Bitcoin, Explained 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.   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 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 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.   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 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.   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/ #BitcoinExplained #BitcoinPrice #BitcoinCore #BitcoinMagazine #journalism  #bitcoinnews

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. 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 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/ Evan Kaloudis tells P & Q what hyperbitcoinization means to him. 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/ #bitcoin #bitcoinmagazine #hyperbitcoinization #money #whatismoney #whatisbitcoin #crypto #cryptocurrencies #globalmarkets

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. Jameson Lopp’s blog post: https://blog.lopp.net/has-bitcoin-ever-hard-forked/

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

In this episode of Bitcoin, Explained (formerly known as The Van Wirdum Sjorsnado) hosts Aaron van Wirdum and Sjors Provoost discuss the Chivo application, the Bitcoin wallet, and payment terminal provided by the government of El Salvador. This episode is a little bit different from other episodes of Bitcoin, Explained, because the Chivo app is closed source software. Instead of analyzing the source code and design of the application, Aaron and Sjors have to rely on Aaron’s personal experience with the wallet and payment terminal or what he remembers of that personal experience. The episode opens with some general information about the Chivo Wallet, like why it was developed and who developed it (insofar anything is known about that). Aaron and Sjors go on to discuss Aaron’s experiences with the wallet and speculate what that means for the design. After that, they discuss the design of the payment terminal that’s included in the application, and also briefly touch on the Chivo ATMs that have been deployed across the country. Finally, Aaron and Sjors discuss the difference in philosophy between the design of the Chivo application and Bitcoin’s free and open-source software culture. --------------------------------------------- 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/

The Van Wirdum Sjorsnado has rebranded, and is now called Bitcoin, Explained! In this episode of Bitcoin, Explained, hosts Aaron van Wirdum and Sjors Provoost discuss Bitcoin Core 22.0, the latest major release of the Bitcoin Core software client, currently the de facto reference implementation of the Bitcoin protocol. Aaron and Sjors highlight several improvements to the Bitcoin Core software. The first of these is hardware wallet support in the graphical user interface (GUI). While hardware wallet support has been rolling out across several previous Bitcoin Core releases, it is now fully available in the GUI. The second highlighted upgrade is support for the Invisible Internet Project (I2P), a Tor-like internet privacy layer. Aaron and Sjors also briefly touch on the differences between I2P and Tor. The third upgrade discussed in the episode is Taproot support. While Taproot activation logic was already included in Bitcoin Core 0.21.1 Bitcoin Core 22.0 is the first major Bitcoin Core release ready to support Taproot when it activates this November, and includes some basic Taproot functionality. The fourth upgrade that Aaron and Sjors discuss is an update to the testmempoolaccept logic, which paves the way to a bigger package relay upgrade. This could in a future release allow transactions to be transmitted over the Bitcoin network in packages including several transactions at the same time. Additionally, Aaron and Sjors briefly discuss an extension to create multisig and add multisig address, the new NAT-PMP option, and more.

Sjors is back! In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss BOLT 12 (Basis of Lightning Technology 12), a newly proposed Lightning Network specification for “offers”, a type of “meta invoices” designed by c-lightning developer Rusty Russell. Where coins on Bitcoin’s base layer are sent to addresses, the Lightning network uses invoices. Invoices communicate the requested amount, node destination, and the hash of a secret which is used for payment routing. This works, but has a number of limitations, Sjors explains, notably that the amount must be bitcoin-denominated (as opposed for fiat denominated), and the invoice can only be used once. BOLT 12, which has been implemented in c-ligtning, is a way to essentially refer a payer to the node that is to be paid, in order to request a new invoice. While the BOLT 12 offer can be static and reusable — it always refers to the same node — the payee can generate new invoices on the fly when requested, allowing for much more flexibility, Sjors explains. Finally, Aaron and Sjors discuss how the new BOLT 12 messages are communicated over the Lightning Network through an update to the BOLT 7 specification for message relay.

In this episode of The Van Wirdum Sjorsnado, Aaron van Wirdum hosts one more interview without his regular cohost Sjors Provoost. Instead, he is joined by Blockstream’s Lawrence Nahum, one of the developers behind the Jade wallet, and Ben Kaufman, one of the developers of the Spectre wallet, which is specifically designed to work with hardware wallets. Aaron, Lawrence and Ben talk about what hardware wallets are, and discuss the design tradeoffs that different hardware wallets have taken by focussing on the Trezor, Ledger and ColdCard specifically. In this light, Lawrence and Ben explain what secure elements and secure chips are, and why some hardware wallets choose to rely on using such chips more than others. Then, Lawrence explains which tradeoffs the Jade wallet makes. He also details how an additional server-based security step is used to further secure the Jade wallet, and briefly outlines some additional differences in hardware wallet designs, for example those focused on usability. Finally, Aaron, Lawrence and Ben discuss whether the concept of hardware wallets are a good idea in the first place, or if it would perhaps be better to use dedicated smartphones to store your bitcoin. And don’t worry, Sjors will be back for episode 44!

A Bitcoin Beach special! In this episode of The Van Wirdum Sjorsnado host Aaron van Wirdum speaks with Bitcoin Beach Wallet developer Nicolas Burtey — without cohost Sjors Provoost this time. Aaron and Nicolas met up in El Zonte, El Salvador — which has been dubbed Bitcoin Beach — to discuss the Bitcoin Beach Wallet, a Bitcoin and Lightning wallet specifically designed for use in the small Central American coastal town frequented by surfers and, now, bitcoiners. Aaron and Nicolas discuss the pros and cons of custodial and non-custodial Lightning wallets, and Nicolas explains why he opted to make the Bitcoin Beach Wallet a shared-custodial wallet, and what that means exactly. They go one to discuss some of the design decisions and tradeoffs that the Bitcoin Beach Wallet has made, which include ledger-based payments between Bitcoin Beach Wallet users as well as the webpage-based zero invoice payments to facilitate payments from other Lightning wallets. while Nicolas speculates about a potential cross-wallet user account system to further improve the Lightning user experience over time. Aaron and Nicolas also discuss some of the subtle incompatibilities between different Lightning wallets that use different techniques for routing payments, privacy considerations versus user experience in a community like El Zonte’s, and more.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost are joined by Lightning developer Joost Jager to discuss everything about Lightning Network routing. The Lightning Network — Bitcoin’s Layer Two protocol for fast and cheap payments — consists of a network of payments channels. Each payment channel exists between two Lightning users. But even if two users don’t have a payment channel between themselves directly, they can pay each other though one or several other Lightning users, who in that case forward the payment from the payer to the payee. The challenge is that a payment path across the network must be found, which allows the funds to move from the payer to the payee, and ideally the cheapest, fastest and most reliable payment path available. Joost explains how Lightning nodes currently construct a map of the Lightning Network, and what information about all of the (publicly visible) payment channels is included about in that map. Next, he outlines on what basis Lightning nodes calculate the best path over the network to reach the payee, and how the performance of this route factors into future path finding calculations. Finally, Aaron, Sjors and Joost discuss some (potential) optimizations to benefit Lightning Network routing, such as rebalancing schemes and Trampoline Payments.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss the lock-in of the Taproot soft fork upgrade. As discussed in previous episodes, Taproot is a Bitcoin protocol upgrade that will make smart contracts more compact, private and flexible. Aaron and Sjors also discussed the Taproot upgrade process in prior episodes, including the Speedy Trial activation method adopted by Bitcoin Core. About a week ago, the Speedy Trial signaling threshold was reached, which means Taproot is locked in and will activate later this year. Aaron and Sjors go into further detail about what this means exactly, and what needs to happen before Taproot can ultimately be used on the Bitcoin network safely. Sjors also explains how upcoming Bitcoin Core releases will handle the Taproot upgrade, and what the Bitcoin Core wallet software will and will not enable, while also touching on potential use-cases enabled by the upgrade. Finally, Aaron and Sjors discuss the Speedy Trial activation process itself, and in particular the lessons learned by it, which could in turn inform future soft fork upgrades. They also briefly speculate which protocol upgrades may be next in line.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost explain what Bitcoin Improvement Proposals (BIPs) are, and how the BIP process works. They discuss why the BIP process is a useful, yet non-binding convention within Bitcoin’s technical community. Aaron and Sjors start off by explaining what a BIP is exactly— and what it is not. They also explain that only improvements to Bitcoin software that affects other projects require a BIP. The two go on to dive into the history of the BIP process a little bit, noting that the format was introduced by Libbitcoin developer Amir Taaki and later updated by Bitcoin Knots maintainer Luke-jr. Finally, Aaron and Sjors explain how the BIP process itself works, that is, how a proposal can be turned into a BIP, and eventually be implemented in software. They also briefly explain how the BIP process could become corrupted, and why that wouldn’t be a very big deal. This episode was originally scheduled to be aired on Friday the 4th of June, but was delayed due to last week's Bitcoin 2021 conference in Miami.

In this Episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss CVE-2021-31876, a bug in the Bitcoin Core code that affects replace-by-fee (RBF) child transactions. The CVE (Common Vulnerabilities and Exposures) system offers an overview of publicly known software bugs. A newly discovered bug in the Bitcoin Core code was recently discovered and disclosed by Antoine Riard, and added to the CVE overview. Aaron and Sjors explain that the bug affects how RBF logic is handled by the Bitcoin Core software. When one unconfirmed transaction includes an RBF flag (which means it should be considered replaceable if a conflicting transaction with a higher fee is broadcast over the network) any following transaction that spends coins from the original transaction should also be considered replaceable — even if the second transaction doesn’t itself have an RBF flag. Bitcoin Core software would not do this, however, which means the second transaction would in fact not be considered replaceable. This is a fairly innocent bug; in most cases the second transaction will still confirm eventually, while there are also other solutions to speed confirmation up if the included fee is too low. But in very specific cases, like some fallback security mechanisms on the Lightning Network, the bug could in fact cause complications. Aaron and Sjors try to explain what such a scenario would look like — badly.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss the emergence of Mara Pool, the American Bitcoin mining pool operated by Marathon Digital Holdings, which claims to be fully compliance with US regulations. More generally, Aaron and Sjors discuss the prospects of mining censorship, what that would mean for Bitcoin, and what can be done about it. Mara Pool claims to be fully compliant with US regulations, which means it applies anti-money laundering (AML) checks and ad hers to the sanction list of the Office of Foreign Asset Control (OFAC). While details have not been made explicit, this presumably means that this pool will not include transactions in their blocks if these transactions send coin to or from Bitcoin addresses that have been included on an OFAC blacklist. Aaron and Sjors discuss what it means that a mining pool is now censoring certain transactions, and they go on to expand what it could look like if this practice gets adopted more widely. They consider what censoring mining pools could accomplish if they ever get close to controlling a majority of hash power, and what Bitcoin users could potentially do in such a scenario (if anything).

The Van Wirdum Sjorsnado 36 — Speedy Trial And The LOT=True Client   In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discussed the final implementation details of Speedy Trial, the Taproot activation mechanism included in Bitcoin Core 0.21.1. Van Wirdum and Provoost also compared Speedy Trial to the alternative BIP 8 LOT=true activation client. After more than a year of deliberation, the Bitcoin Core project has merged Speedy Trial as the (first) activation mechanism for the Taproot protocol upgrade. Although van Wirdum and Provoost had already covered Taproot, the different possible activation mechanisms and Speedy Trial specifically in previous episodes, in this episode they laid out the final implementation details of Speedy Trial.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss SIGHASH_ANYPREVOUT, a proposed new sighash flag that would enable a cleaner version of the Lightning Network and other Layer Two 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.Aaron and Sjors explain 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 context of Eltoo, a proposed Layer Two protocol that would enable a new version of the Lightning Network. Where 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, Aaron and Sjors explain how SIGHASH_ANYPREVOUT would do away with this requirement.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss the Erlay protocol. Erlay is a proposal to reduce the bandwidth required to run a Bitcoin node, which has been proposed and developed by University of British Columbia researchers Gleb Naumenko, Alexandra Fedorova and Ivan Beschastnikh; Blockstream engineer Pieter Wuille; and independent Bitcoin Core contributor Gregory Maxwell. Bitcoin nodes use bandwidth to receive and transmit both block data as well as transaction data. Reducing the amount of bandwidth a node requires to do this, would make it cheaper to run a node. Alternatively, it allows nodes to connect to more peers without increasing its bandwidth usage.   In the episode, Aaron and Sjors explain that Erlay uses set reconciliation to reduce the amount of data nodes need to share transactions. More specifically, Erlay uses a mathematical trick called Minisketch. This solution is based on pre-existing mathematical formulas used in biometrics technology. Aaron and Sjors outline how this trick is applied in the context of Bitcoin to let different nodes sync their mempools: the sets of transactions they’ve received in anticipation of a new block, or, in the case of a miner, to include in a new block.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost are once again joined by Ruben Somsen. The trio discusses RGB tokens, a Layer Two protocol for Bitcoin to support alternative currency and token schemes (like the currently popular non-fungible tokens, or NFTs). Aaron, Sjors and Ruben explain that the Bitcoin blockchain has been (ab)used by users to host data since the project’s early days. This was initially done through otherwise-useless transaction outputs, which meant that all Bitcoin users had to store this data locally. A feature called OP_RETURN later limited this burden.They also explain that people have been using the Bitcoin blockchain to host alternative currency and token schemes for a long time.  More resources on RGB Tokens: https://youtu.be/PgeqT6ruBWU  

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Segregated Witness, also known as SegWit. SegWit was the last soft fork to have been activated on the Bitcoin network in the summer of 2017, and the biggest Bitcoin protocol upgrade to date. In short, SegWit allowed transaction data and signature data to be separated in Bitcoin blocks. In this episode, Aaron and Sjors explain how this works, and that this offered four main benefits: First, SegWit solved the transaction malleability issue, where transaction IDs could be altered without invalidating the transactions themselves. Solving the transaction malleability issue itself in turn enabled second layer protocols like the Lightning Network. Second, SegWit offered a modest block size limit increase by discounting the “weight” of witness data, most notably signatures. Importantly, this could be done without the need for a hard fork. Third, SegWit’s script versioning allows for easier upgrades to new transactions types. The anticipated Taproot upgrade could be a first example of this feature. And fourth, input signing resolved some edge case problems where wallets needed to make sure they don’t overpay in transaction fees.. Hardware wallets benefit from this solution in particular.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Speedy Trial, the proposed Taproot activation mechanism that has been gaining traction in recent weeks. Aaron and Sjors explain that Speedy Trial would give miners three months to signal support for the Taproot upgrade with their hash power. If a supermajority of miners signal support for the upgrade within these thee months, Taproot will activate a couple of months later: six months since the release of the software client that includes the activation logic. If miners don’t signal support within three months, the upgrade will expire, and a new upgrade path can be considered. (It is as of yet not defined what the potential alternative upgrade path would look like.) Aaron explains that Speedy Trial was born out of a compromise between developers and users who preferred different upgrade mechanisms for the Taproot soft fork, while Sjors details what some of the more technical implementation considerations of Speedy Trial are, like the benefits of using block heights instead of time stamps, and the extended delay between signaling and enforcement. Finally, Aaron and Sjors discuss some of the downsides and risks of Speedy Trial.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss hardware wallet integration into Bitcoin Core, one of the ongoing projects that Sjors regularly contributes to himself. Hardware wallets are a popular solution for storing private keys offline, to minimize the risk that hackers gain access to the corresponding coins. They are used in combination with regular software wallets to sign transactions in such a way that the private keys never leave the device.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss activation of the Taproot soft fork upgrade, and more specifically, the lock-in on timeout (LOT) parameter. The LOT parameter can be set to either “true” (LOT=true) or “false” (LOT=false). LOT=false resembles how several previous soft forks were activated. Miners would have one year to coordinate Taproot activation through hash power; if and when a supermajority (probably 90 percent) of miners signal readiness for the upgrade, the soft fork will activate. But if this doesn’t happen within (probably) a year, the upgrade will expire. (After which it could be redeployed.)LOT=true also lets miners activate the soft fork through hash power, but if they fail to do this within that year, nodes will activate the soft fork regardless.Aaron and Sjors discuss the benefits and detriments of each option. This also includes some possible scenarios of what could happen if some users set LOT to true, while other users set LOT to false, and the associated risks. Finally, Aaron and Sjors discuss what they think is most likely going to happen with Taproot activation.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Bitcoin addresses. Every Bitcoin user has probably at one point used Bitcoin addresses, but what are they, exactly? Aaron and Sjors explain that Bitcoin addresses are not part of the Bitcoin protocol. Instead, they are conventions used by Bitcoin (wallet) software to communicate where coins must be spent to: either a public key (P2PK), a public key hash (P2PKH), a script hash (P2SH), a witness public key hash (P2WPKH), or a witness script hash (P2WSH). Addresses also include some meta data about the address type itself. Bitcoin addresses communicate these payment options using their own “numeric systems”, Aaron and Sjors explain. The first version of this was base58, which uses 58 different symbols to represent numbers. Newer address types, bech32 addresses, instead use base32 which uses 32 different symbols to represent numbers. Aaron and Sjors discuss some of the benefits of using Bitcoin addresses in general. and bech32 addresses in specific. In addition, Sjors explains that the first version of bech32 addresses included a (relatively harmless) bug, and how a newer standard for bech32 addresses has fixed this bug.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost are once again joined by Ruben Somsen. This time, they discuss one of Ruben’s own proposals, called Softchains. Softchains are a type of two-way peg sidechains that utilize a new type of consensus mechanism: proof-of-work fraud proofs (or as Sjors prefers to call them, proof-of-work fraud indicators). Using this consensus mechanism, users don’t validate the content of each block, but instead only check the proof of work header, like Simplified Payment Verification (SPV) clients do. But using proof-of-work fraud proofs, users do validate the entire content of blocks any time a blockchain fork occurs. This offers a security model in between full node security and SPV security. Ruben explains that by using proof-of-work fraud proofs for sidechains to create Softchains, Bitcoin full nodes could validate entire sidechains at minimal cost. This new model might be useful for certain types of sidechains, most notably “block size increase” sidechains that do nothing fancy but do offer more transaction capacity. Aaron, Sjors and Ruben also discuss some of the downsides of the Softchain model.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Replace By Fee (RBF). RBF is a trick that lets unconfirmed transactions be replaced by conflicting transactions that include a higher fee. With RBF, users can essentially bump a transaction fee to incentivize miners to include the transaction in a block. Aaron and Sjors explain three advantages of RBF: the option the “speed up” a transaction (1), which can in turn result in a more effective fee market for block space (2), as well as the potential to make more efficient use of block space by updating transactions to include more recipients (3). The main disadvantage of RBF is that it makes it slightly easier to double spend unconfirmed transactions, which was also at the root of last week’s “double spend” controversy that dominated headlines. Aaron and Sjors discuss some solutions to diminish this risk, including “opt-in RBF” which is currently implemented in Bitcoin Core. Finally, Sjors explains in detail how opt-in RBF works in Bitcoin Core, and which conditions must be met before a transaction is considered replaceable. He also notes some complications with this version of RBF, for example in the context of the Lightning Network.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss Compact Client Side Filtering, also known as Neutrino. Compact Client Side Filtering is a solution to use Bitcoin without needing to download and validate the entire blockchain, and without sacrificing your privacy to someone who operates a full node (and therefore did download and validate the entire blockchain). Downloading and validating the entire Bitcoin blockchain can take a couple of days even on a standard laptop, and much longer on smart phones or other limited-performance computers. This is why many people prefer to use light clients. These aren’t quite as secure as full Bitcoin nodes, but they do require fewer computational resources to operate. Some types of light clients — Simplified Payment Verification (SPV) clients — essentially ask nodes on the Bitcoin network about the particular Bitcoin addresses they are interested in, to check how much funds they own. This is bad for privacy, since the full node operators learns which addresses belong to the SPV user. Compact Client Side Filtering is a newer solution to accomplish similar goals as SPV, but without the loss of privacy. This works, in short, by having full node operators create a cryptographic data-structure that tells the light client user whether a block could have contained activity pertaining to its addresses, so the user can keep track of its funds by downloading only a small subset of all Bitcoin blocks. Aaron and Sjors explain how this works in more detail, and discuss some of the tradeoffs of this solution.

In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discuss the newly released Bitcoin Core 0.21.0. Bitcoin Core 0.21.0 is the 21st and latest major release of the Bitcoin Core software, the oldest and most important Bitcoin node implementation, which is often also regarded as the reference implementation for the Bitcoin protocol. Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Follow Bitcoin Magazine @BitcoinMagazine

In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost are once again joined by Ruben Somsen. The trio discusses Drivechain, a sidechain project spearheaded by Paul Sztorc.Sidechains are alternative blockchains, where coins are pegged to bitcoin. This should make the sidechain coins interchangeable with bitcoin and therefore carry an equal value. In a way, sidechains let users “move” bitcoin across blockchains, where they are subject to different protocol rules, allowing for greater transaction capacity, more privacy, and other benefits.Aaron, Sjors and Ruben explain that Drivechain consists of two main innovations. The first is blind merged mining, which lets Bitcoin miners secure the drivechain with their existing hash power, but without necessarily needing to validate everything that happens on the sidechain. The second is hashrate escrows, which lets miners “move” coins from the Bitcoin blockchain to the sidechain and back. The hosts also discuss some of the benefits as well as complications with Drivechain, most notably the security implications of letting miners control the pegging out process. They consider the arguments why this process is incentive compatible (in other words: secure) — or why it might not be.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss the basics of the Lightning Network, Bitcoin’s Layer 2 protocol for cheaper, faster and potentially more private transactions.

In this episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss why it matters that Bitcoin software is open source… and why even open source software doesn't necessarily solve all software-specific trust issues. In theory, the fact that most Bitcoin nodes, wallets and applications are open source should ensure that developers can’t include malicious code in the programs: anyone can inspect the source code for malware. In practice, however, the number of people with enough expertise to do this is limited, while the reliance of some Bitcoin projects on external code libraries (“dependencies”) makes it even harder. Furthermore, even if the open source code is sound, this doesn’t guarantee that the binaries (computer code) really correspond with the open source code. Aaron and Sjors explain how this risk is largely mitigated in Bitcoin through a process called Gitian building, where several Bitcoin Core developers sign the binaries if, and only if, they all produced the exact same binaries from the same source code. This requires special compiler software. Finally, Aaron and Sjors discuss Guix, a relatively new project that goes above and beyond the Gitian process, to minimize the level of trust required to turn source code into binaries — including trust in the compiler itself.  

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss RSK’s shift from a federated sidechain model to the project’s new Powpeg solution. RSK is a merge mined Ethereum-like Bitcoin sidechain developed by IOVlabs. Bitcoin users can effectively move their coins to this blockchain that operates more like Ethereum, and move the coins back to the Bitcoin blockchain when they so choose. Some Bitcoin miners utilize their hashpower to mine bocks on the sidechain, and earn some extra transaction fees by doing so.The tricky part of any sidechain is allowing users to securely move their coins between blockchains. This is technically done by locking coins on the Bitcoin blockchain and issuing corresponding coins on the sidechain, and vice versa: locking coins on the sidechain to unlock the coins on the Bitcoin blockchain.So far, RSK did this by locking the coins into a multi-signature address, for which the private keys were controlled by a group of well-known companies. A majority of them was needed to unlock the coins, which they were to only do if and when the corresponding sidechain coins were locked.RSK is now switching to a Powpeg model where the keys to the multi-signature address are controlled by special tamper-proof hardware modules that are in turn programmed to only unlock coins on the Bitcoin blockchain if and when the corresponding coins on the sidechain are locked, and the transactions to lock these coins up have a significant number of confirmations.Aaron and Sjors explain how this works exactly, and discuss some of Powpeg’s security tradeoffs.

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discussed Bitcoin mempools, Child Pays For Parent (CPFP) and package relay. Package relay is the project that Gloria Zhao will work on as part of her Brink fellowship, which was announced earlier this week, and would make the Lightning Network more robust (among other benefits). Mempools are the collections of unconfirmed transactions stored by nodes, from which they forward transactions to peers. Miners usually select the transactions from their mempools that include the highest fees, to include these in the blocks they mine. Mempools can get full, however, at which point transactions that pay the lowest fees are ejected. This is actually a problem in context of CPFP, a trick that lets users speed up low-fee transactions by spending the coins from that transactions in a new transaction with a high fee to compensate. Tricks like these can be particularly important in the context of time-sensitive protocols like the Lightning Network. In this episode, van Wirdum and Provoost explained how package relay could enable CPFP, even in cases where low-fee transactions are dropped from mempools, by bundling transactions into packets. And they explore why this may be easier said than done.

In this episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss the Erebus Attack. The episode is a follow-up from last week’s episode on Eclipse Attacks, a type of attack that isolates a Bitcoin node by occupying all of its connection slots to block the node from receiving any transactions. Erebus Attacks are Eclipse Attacks where an attacker essentially spoofs a whole part of the internet. Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In this episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss Eclipse attacks. More specifically, they discuss the 2015 paper “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network,” written by Ethan Heilman, Alison Kendler, Aviv Zohar and Sharon Goldberg, from Boston University and Hebrew University/MSR Israel. Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In this episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss Open Timestamps, a Bitcoin-based time stamping project by applied cryptography consultant and former Bitcoin Core contributor Peter Todd. Open Timestamps leverages the security of the Bitcoin blockchain to timestamp any type of data, allowing for irrefutable proof that that data existed at a particular point in time. Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

On this episode of The Van Wirdum Sjorsnado, Aaron and Sjors are once again joined by Ruben Somsen. This time, the trio doesn’t discuss one of Somsen’s own proposals, but they dive into a concept by Tadge Dryja called Utreexo.   Helpful links: https://www.youtube.com/watch?v=6Y6n88DmkjU   https://bitcoinmagazine.com/articles/bitcoins-growing-utxo-problem-and-how-utreexo-can-help-solve-it   Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Follow Ruben Somsen @SomsenRuben   Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

On this episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss “Assume UTXO”, a proposal and project by Chaincode Labs alumni James O’Beirne.   One of the biggest bottlenecks for scaling Bitcoin — if not the biggest one — is initial block download: the time it takes for a Bitcoin node to synchronize with the Bitcoin network, as it needs to process all historic transactions and blocks in order to construct the latest UTXO-set: the current state of bitcoin-ownership.   Aaron and Sjors explain some of the ways sync-time has been sped up over time. First, sync-time was improved through “Headers First” synchronization, which ensures that new Bitcoin nodes don’t waste time validating (potentially) weaker blockchains. In recent years, sync-time has been improved with “Assume Valid”, an optional shortcut that lets nodes skip signature verification of older transactions, instead trusting that the Bitcoin Core development process in combination with the resource-expensive nature of mining offers a reliable version of transaction history. Finally, they explain how the security assumptions underpinning Assume Valid could be extended to allow for the potential future upgrade Assume UTXO to offer new Bitcoin Core users a speedy solution to get up to speed with the Bitcoin network, sacrificing a minimal amount of security during the initial bootstrapping phase.   Helpful Links:    Chaincode podcast about the same: https://www.youtube.com/watch?v=knBHvzKsIOY   Pull request: https://github.com/bitcoin/bitcoin/issues/15605   Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

Bitcoin Core 0.21 will support Tor v3 addresses. Aaron and Sjors explain what this means and why it matters, and also discuss how new Bitcoin nodes find existing Bitcoin nodes when they bootstrap to the network. Helpful Links: * Tor V3 (onion) address support in Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/19954 * the ADDRv2 message added in BIP155 that allows nodes to gossip those new Tor addresses: https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki#Specification * DNS seeds and the bootstrap problem: https://stackoverflow.com/questions/41673073/how-does-the-bitcoin-client-determine-the-first-ip-address-to-connect Timestamps: 00:00 - 00:34 - intro  1:02 - 2:10: how Tor Works 2:25 - 3:03: benefits of running a bitcoin node behind tor.  7:12 - 8:19 Discussing how Bitcoin node gossip addresses.  8:56 - 10:40 Explaining how DNS works  12:30 - 13:30: DNS is storing list of bitcoin nodes.  Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Follow Ruben Somsen @SomsenRuben Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In this episode of The Van Wirdum Sjorsnado, Ruben Somsen returns to explain his proposal to combine blind merged mining and perpetual one-way pegs in order to create a new type of sidechain. The bad news: it won't make you rich but it could help scale Bitcoin! Helpful Links: https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302 Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Follow Ruben Somsen @SomsenRuben Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In this episode Sjors and Aaron discuss Jose Femenias' Easypaysy proposal, an account system for Bitcoin, on Bitcoin. They also announce groundbreaking news: The Van Wirdum Sjorsnado now has its own RSS-feed! Aaron's article covering Easypaysy on Bitcoin Magazine https://bitcoinmagazine.com/articles/bitcoin-need-accounts-one-developer-thinks-figured The BIP in Github https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost   Music! Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

Sjors and Aaron discuss Signet, a new type of testnet for Bitcoin that was merged into Bitcoin Core last week. They also discuss the original version of testnet and its problems, as well as alternative testing environment regtest. Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

Schnorr signature support was merged into the libsec256k1 library last week. In the episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss what the libsecp256k1 library is, why it matters for Bitcoin, and what it means that Schnorr signature support was merged. Sjors also briefly explains what he ultimate send RPC is, his own pull request that was recently merged into Bitcoin Core as well. Helpful Links: The Power of Schnorr: https://bitcoinmagazine.com/articles/the-power-of-schnorr-the-signature-algorithm-to-increase-bitcoin-s-scale-and-privacy-1460642496 Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost

Aaron and Sjors welcome their first guest on to the show, Ruben Somsen, to discuss his proposals for Statechains on Bitcoin! Statechains allow you to send keys not UTXO and it offers quite a few scaling and functionality improvements!  Helpful Links: Ruben's presentation on Bitcoin Magazine about Statechains: https://youtu.be/CKx6eULIC3A Aaron's Bitcoin Magazine article on Statechains: https://bitcoinmagazine.com/articles/statechains-sending-keys-not-coins-to-scale-bitcoin-off-chain Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost

In this episode of the Van Wirdum Sjorsnado, Sjors and Aaron explain what an xpub is and how it is used by Bitcoin wallets. Helpful Links: http://rosenbaum.se/book/grokking-bitcoin-4.html#_hierarchical_deterministic_wallets https://walletsrecovery.org Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In this episode of the Van Wirdum Sjorsnado, Sjors and Aaron discuss the future of Bitcoin Scaling. This podcast is all about Taproot and the cool feature it enables called Payment pools.  Topics What are payment pools?   Why they need Taproot.    The UX of sharing UTXOs   How Payment pools work with lightning Helpful Links: https://bitcoinmagazine.com/articles/building-on-taproot-payment-pools-could-be-bitcoins-next-layer-two-protocol Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In this episode of the Van Wirdum Sjorsnado, Sjors explains the "time-warp attack" on Bitcon and Aaron explains the unfolding drama with the bcash difficulty adjustment. Helpful Links: https://bitcoinmagazine.com/articles/miners-are-milking-bcashs-difficulty-adjustments-and-why-problem1 https://bitcoinmagazine.com/articles/why-bcash-mining-shouldnt-affect-bitcoin-much-bitcoin-mining-could-ruin-bcash https://read.cash/@jtoomim/dark-secrets-of-the-grasberg-daa-a9239fb6 https://blog.bitcoinabc.org/2020/07/23/announcing-the-grasberg-daa/ https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In this episode of the Van Wirdum Sjorsnado, Aaron and Sjors dive into Miniscript and how it makes using Bitcoin Script much easier.  Helpful Links: https://bitcoinmagazine.com/articles/miniscript-how-blockstream-engineers-are-making-bitcoin-programming-easyer Support the Show! Follow Bitcoin Magazine on Twitter @BitcoinMagazine Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music: Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In the third episode of The Van Wirdum Sjorsnado, Aaron and Sjors break down and explain the different opinions and options available for activating Taproot and potentially future softfork upgrades.    Helpful Links:   Explainer article by Aaron discussing the different upgrade options:  https://bitcoinmagazine.com/articles/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next   Support the Show!    Follow Bitcoin Magazine on Twitter @BitcoinMagazine    Follow Aaron van Wirdum @AaronvanW   Follow Sjors Provoost @provoost   Music:  Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

In the second episode of The Van Wirdum Sjorsnado, Aaron and Sjors break down and explain Taproot, the building blocks that make Taproot possible, and what it enables Bitcoin to do.    Helpful Links:    Taproot Explainer: https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin    Support the Show!    Follow Bitcoin Magazine on Twitter @BitcoinMagazine    Follow Aaron van Wirdum @AaronvanW   Follow Sjors Provoost @provoost   Music:  Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio

Bitcoin Magazine's Technical editor Aaron van Wirdum teams up with Bitcoin core contributor Sjors Provoost to explain Bitcoin one episode at a time. In the debut episode of The Van Wirdum Sjorsnado, Aaron and Sjors break down and explain Partially Signed Bitcoin Transactions (PSBT) and Replace By Fee (RBF) and some really tricky attacks that where recently discovered in Bitcoin.  Helpful Links:  PSBT Attack Vector: https://blog.trezor.io/latest-firmware-updates-correct-possible-segwit-transaction-vulnerability-266df0d2860 RBF Attack Vector: https://zengo.com/bigspender-double-spend-vulnerability-in-bitcoin-wallets/ Support the Show!  Follow Bitcoin Magazine on Twitter @BitcoinMagazine  Follow Aaron van Wirdum @AaronvanW Follow Sjors Provoost @provoost Music:  Song Title: Segwit Sounds By: The NakamoTones Album: Citadel Music Produced by: Bitcoin Audio