Bitcoin, Explained — The Technical Side of Bitcoin

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.

00:00:00 Federated ecash with Ruben Somsen

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.

00:00:00 Why block relay needs less redundant data

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.

00:00:00 Mempools and the proposal to remove them

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

00:00:00 The attack of the fake peers

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.

00:00:00 Eltoo, Lightning penalties and channel backups

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://watchbmtv.substack.com/?showWelcome=true

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

00:00:00 Lightning reliability and hidden channel balances

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.

00:00:00 Chivo: a first look at the rollout

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.

00:00:00 Bitcoin, Explained and Bitcoin Core 22.0

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.

00:00:00 BOLT 12 and Lightning protocol standards

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!

00:00:00 Hardware-wallet basics with Lawrence Nahum and Ben Kaufman