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.
2021 episodes (30)
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
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.
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.
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.