I jumped on the Nostr bandwagon. You can find my by searching sjors@sprovoost.nl or via my public key: npub1s6z7hmmx2vud66f3utxd70qem8cwtggx0jgc7gh8pqwz2k8cltuqrdwk4c
Todays newsletter starts chapter 5 from Bitcoin: A Work in Progress.
One of the biggest bottlenecks — if not the biggest one — for scaling Bitcoin is initial block download. This is the time it takes for a Bitcoin node to synchronize with the Bitcoin network, as it needs to process all historic transactions and blocks to construct the latest unspent transaction output (UTXO) set, i.e. the current state of Bitcoin ownership.
This chapter will cover some of the ways sync time has been sped up over time. It was first improved through Headers First synchronization, which ensures that new Bitcoin nodes don’t waste time validating (potentially) weaker blockchains. One of several recent improvements to synchronizing time is called Assume Valid, a default 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.
It’ll also discuss how the security assumptions underpinning Assume Valid could be extended to allow for a potential future upgrade, AssumeUTXO, to offer new Bitcoin Core users a speedy solution to get up to speed with the Bitcoin network by syncing the most recent blocks first and checking historical blocks in the background later.
In addition to the accompanying Bitcoin, Explained episode 14, you can also listen to an episode of The Chaincode Podcast with AssumeUTXO author James O’Beirne, which covers the same topics as this chapter.
When you turn on your Bitcoin node it finds and connects to other peers, as we explained in chapter 2. It then proceeds to download the blockchain.
The most naive way of downloading the blockchain would be to just ask your peers to send you everything they’ve got. That’s not a good idea, because if any of your peers are malicious, they could trick you into downloading terabytes of fake blocks, until you run out of disk space and your node crashes.
To prevent such abuse the initial version of Bitcoin would first ask nodes for a block header. This header includes the proof-of-work, which — as the term suggests — proves that some work went into creating the block. By checking the proof in this header before fetching the block itself, it makes it more expensive for an attacker to produce enough fake blocks to overflow your hard disk. Once the block is fetched and checked, your node asks for the next header, and so forth, processing headers and blocks sequentially.
Although this protects against the most trivial form of block spam, we’re not out of the woods. The approach is still very myopic, in that your node only checks the blocks right in front of it, without seeing the big picture.
The problem with this is you don’t know if you’re following a dead end, and someone could feed your node a long branch of blocks that aren’t part of the most proof-of-work chain. Nodes that just came online are especially vulnerable to this. This is because the proof-of-work difficulty has historically increased. It’s expensive to create dead-end branches that start from recent blocks, because many miners are competing to produce blocks, pushing up the cost of creating a block. But if an attacker starts from a very old block, from a time when there were fewer and less powerful miners, then the cost to produce these blocks is very low.
So an attacker can create a chain of very low difficulty blocks that branch off from some old block. If your node is new in town, when it sees two — or even thousands of — possible branches, it doesn’t know which is the real one. If it picks the branch from the attacker first, it can end up wasting lots of time and computer resources to verify the blocks. Even though the proof-of-work difficulty of these blocks is low, it’s not any easier for a node to verify the transactions; these dead-end branches may be filled to their one megabyte maximum with specially crafted transactions that are verified extra slowly.
In addition to bogging down nodes with dead-end branches of low difficulty blocks, there’s also the issue of eclipse attacks, which we’ll cover in chapter 7.