Skip to main content
How Federated eCash And Bitcoin Can Embed Properties Of A Digital Cash System
Skip to main content
Tag: Bitcoin Explained
Skip to main content
Explaining How Compact Blocks Can Make Bitcoin More Efficient
Skip to main content
Discussing The Fake Peer Attack On Bitcoin
Skip to main content
A First Look At The Chivo App, El Salvador’s Bitcoin Wallet
Watch This Episode On YouTube
Listen To This Episode:
In this episode of “Bitcoin, Explained” (formerly known as “The Van Wirdum Sjorsnado”), hosts Aaron van Wirdum and Sjors Provoost discussed 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, van Wirdum and Provoost had to rely on van Wirdum’s personal experience with the wallet and payment terminal or what he remembers of that personal experience.
“It’s nice when it’s open source and transparent,” said Provoost. “The Chivo system is not really that.”
The episode opens with some general information about the Chivo wallet, such as why it was developed and who developed it (insofar as anything is known about that). Van Wirdum and Provoost went on to discuss van Wirdum’s experiences with the wallet and speculated what that means for the design. After that, they discussed the design of the payment terminal that’s included in the application, and also briefly touched on the Chivo ATMs that have been deployed across the country.
“You could send [bitcoin] to another Chivo Wallet, but not to an external wallet, so any merchant using Chivo would be able to accept it, but any merchant not using Chivo would not be able to accept it,” Provoost said. “Which is the exact opposite of the point of being interoperable.”
Finally, van Wirdum and Provoost discussed the difference in philosophy between the design of the Chivo application and Bitcoin’s free and open-source software culture.
Bitcoin Core 22.0 Explained
The Van Wirdum Sjorsnado has rebranded, and is now called Bitcoin, Explained!
Watch This Episode On YouTube
Listen To This Episode:
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.
Van Wirdum and Provoost 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.
Van Wirdum and Provoost 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.
Explaining Basis Of Lightning Technology (BOLT) 12
Explaining Lightning Network specification BOLT 12 and how it works with the Bitcoin Layer 2 protocol.
Watch This Episode On YouTube
Listen To This Episode:
Sjors is back! In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discussed BOLT 12 (Basis of Lightning Technology 12), a newly-proposed Lightning Network specification for “offers,” a type of “meta invoice” 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,
Provoost explained the details, notably that the amount must be bitcoin-denominated (as opposed to fiat-denominated), and that the invoice can only be used once. BOLT 12, which has been implemented in c-lightning, 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, Provoost explained.
Finally, van Wirdum and Provoost discussed how the new BOLT 12 messages are communicated over the Lightning Network through an update to the BOLT 7 specification for message relay.