Bitcoin, Explained — The Technical Side of Bitcoin

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