diff --git a/data/blog/andrew-toth-receives-lts-grant.mdx b/data/blog/andrew-toth-receives-lts-grant.mdx index a9c30e1ef..1a5490fab 100644 --- a/data/blog/andrew-toth-receives-lts-grant.mdx +++ b/data/blog/andrew-toth-receives-lts-grant.mdx @@ -14,8 +14,8 @@ on performance and privacy enhancements that improve the experience of running a fully validating node. Andrew is an active, long-time [contributor to Bitcoin Core], with contributions -spanning initial block download (IBD), block-connection logic, caching behavior, -and RPC performance. +spanning [Initial Block Download](/topics/initial-block-download) (IBD), +block-connection logic, caching behavior, and RPC performance. His improvements to [IBD and block-connection speed for pruned nodes] have provided significant changes for users operating with limited disk resources, diff --git a/data/blog/bitcoin-grants-july-2024.mdx b/data/blog/bitcoin-grants-july-2024.mdx index b32d736d0..03e66f79f 100644 --- a/data/blog/bitcoin-grants-july-2024.mdx +++ b/data/blog/bitcoin-grants-july-2024.mdx @@ -217,8 +217,8 @@ Licenses: [MIT](https://github.com/bitcoindevkit/bdk/blob/master/LICENSE-MIT)/[A ### Utreexo Utreexo utilizes Merkle trees to provide an alternate structure for access to -Bitcoin data, enabling compact state nodes, parallelization of the Initial Block -Download (IBD), and thereby wider distribution of functional Bitcoin nodes. This +Bitcoin data, enabling compact state nodes, parallelization of the [Initial Block +Download](/topics/initial-block-download) (IBD), and thereby wider distribution of functional Bitcoin nodes. This opens the door to browser-based and smaller low-power devices to become Bitcoin nodes—including mobile devices! diff --git a/data/blog/caring-for-bitcoin-core.mdx b/data/blog/caring-for-bitcoin-core.mdx index 229d78100..a839237d3 100644 --- a/data/blog/caring-for-bitcoin-core.mdx +++ b/data/blog/caring-for-bitcoin-core.mdx @@ -64,8 +64,7 @@ License: MIT ### @davidgumberg (David Gumberg) [David](https://github.com/davidgumberg) focuses on optimizing the [Initial -Block Download -(IBD)](https://developer.bitcoin.org/devguide/p2p_network.html#initial-block-download) +Block Download (IBD)](/topics/initial-block-download) process for Bitcoin Core nodes. IBD involves downloading and verifying the entire Bitcoin blockchain, a process that can be resource-intensive in terms of time, bandwidth, and storage. The project aims to reduce these challenges, diff --git a/data/blog/l0rinc-receives-lts.mdx b/data/blog/l0rinc-receives-lts.mdx index 795d1c7e7..1200c7676 100644 --- a/data/blog/l0rinc-receives-lts.mdx +++ b/data/blog/l0rinc-receives-lts.mdx @@ -51,7 +51,7 @@ making a one-time or recurring donation to the [General Fund]. [l0rinc]: https://github.com/l0rinc [January 2025]: /blog/more-for-core#l0rinc [Bitcoin Core]: /projects/bitcoin-core -[initial block download]: https://bitcoin.org/en/full-node#initial-block-downloadibd +[initial block download]: /topics/initial-block-download [IBD benchmarks]: https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2388503588 [profiling Bitcoin Core]: https://github.com/bitcoin/bitcoin/issues/32832 [Raspberry Pi 4]: https://www.raspberrypi.com/products/raspberry-pi-4-model-b/ diff --git a/data/blog/more-for-core.mdx b/data/blog/more-for-core.mdx index 87cb25a6c..00f2842a7 100644 --- a/data/blog/more-for-core.mdx +++ b/data/blog/more-for-core.mdx @@ -22,8 +22,7 @@ maintaining and improving Bitcoin Core: - [@danielabrozzoni](#danielabrozzoni) Each grantee will focus on key aspects of Bitcoin Core, from enhancing the -[Initial Block -Download](https://bitcoin.org/en/full-node#initial-block-downloadibd) (IBD) +[Initial Block Download](/topics/initial-block-download) (IBD) process and optimizing database performance to deepening code reviews and improving test coverage. Their efforts are essential to maintaining and strengthening Bitcoin's reliability, accessibility, and decentralization. diff --git a/data/blog/red-team-grants-first-set.mdx b/data/blog/red-team-grants-first-set.mdx index 6ea157be8..6c4727e06 100644 --- a/data/blog/red-team-grants-first-set.mdx +++ b/data/blog/red-team-grants-first-set.mdx @@ -86,7 +86,7 @@ contributor, l0rinc [authored around 150 pull requests][l0rinc prs] [provided reviews to more than 400 PRs][l0rinc reviews] by other developers. His work focused on several topics, from testing to benchmarking, with a particular effort on optimizing the -performance of Initial Block Download (IBD) and the memory +performance of [Initial Block Download](/topics/initial-block-download) (IBD) and the memory usage across several parts of the codebase. Since May 2026, l0rinc has been scanning both Bitcoin Core and diff --git a/data/blog/sixteenth-wave-of-bitcoin-grants.mdx b/data/blog/sixteenth-wave-of-bitcoin-grants.mdx index 3445fedb6..617b46e6c 100644 --- a/data/blog/sixteenth-wave-of-bitcoin-grants.mdx +++ b/data/blog/sixteenth-wave-of-bitcoin-grants.mdx @@ -256,7 +256,7 @@ implementation. It provides a modular node, server, and explorer stack together with cross-platform libraries for building Bitcoin applications. The project began in 2011 and produced the first independently implemented Bitcoin full node separate from Bitcoin Core, and it remains under active maintenance with work -toward a version 4 release that emphasizes faster initial block download and +toward a version 4 release that emphasizes faster [Initial Block Download](/topics/initial-block-download) and better scaling with modern hardware. This grant will support work on libbitcoin v4 by developer [pmienk]. Planned diff --git a/data/projects/bitcoin-core.mdx b/data/projects/bitcoin-core.mdx index 161e3f90e..483a5aad4 100644 --- a/data/projects/bitcoin-core.mdx +++ b/data/projects/bitcoin-core.mdx @@ -30,7 +30,7 @@ The [2024 CoreDev contributor survey][coredev-survey] ranked "lack of reviewers" Review is the main bottleneck. Large pull requests can sit for months waiting for reviewers with the time to dig in, test on real hardware, and stay engaged as the patch goes through rebase after rebase. -Andrew Toth is working on a [block validation speedup][validation-pr] that would improve both Initial Block Download and processing at the chain tip. L0rinc is benchmarking Core on everything from cloud servers to Raspberry Pis and looking at ways to cut memory usage. Marco Falke maintains the test framework and CI infrastructure the rest of the project depends on. +Andrew Toth is working on a [block validation speedup][validation-pr] that would improve both [Initial Block Download](/topics/initial-block-download) and processing at the chain tip. L0rinc is benchmarking Core on everything from cloud servers to Raspberry Pis and looking at ways to cut memory usage. Marco Falke maintains the test framework and CI infrastructure the rest of the project depends on. [Private transaction broadcast][priv-broadcast] merged this year. Toth has follow-up work to improve reliability across restarts and give node operators more control over the feature. diff --git a/data/projects/libbitcoin.mdx b/data/projects/libbitcoin.mdx index 2585f46e8..4664178c7 100644 --- a/data/projects/libbitcoin.mdx +++ b/data/projects/libbitcoin.mdx @@ -24,7 +24,7 @@ OpenSats funded [libbitcoin][announcement] to support work toward the v4 stack. ## What's next? -The public direction is clear from the grant announcement. Work is aimed at an early preview of the v4 node, followed by full releases of the node, explorer, and server components. That includes faster initial block download, better scaling across CPU, disk, and network resources, and more integration work across the consolidated stack. +The public direction is clear from the grant announcement. Work is aimed at an early preview of the v4 node, followed by full releases of the node, explorer, and server components. That includes faster [Initial Block Download](/topics/initial-block-download), better scaling across CPU, disk, and network resources, and more integration work across the consolidated stack. Recent public repository activity also shows steady maintenance across the toolkit, including CI updates and ongoing changes in the core, network, database, and server repos. The next step is to turn that active development into a polished v4 release that operators and developers can rely on. diff --git a/data/projects/utreexod.mdx b/data/projects/utreexod.mdx index b4dd0a773..47cae5e41 100644 --- a/data/projects/utreexod.mdx +++ b/data/projects/utreexod.mdx @@ -26,8 +26,9 @@ around the same protocol work. The main tradeoff is bandwidth. `utreexod` uses much less disk I/O and memory than a traditional node, but it downloads extra proof data. It can also start -from a hardcoded UTXO state, which avoids the usual initial block download path -and brings a validating node online much faster. +from a hardcoded UTXO state, which avoids the usual [Initial Block +Download](/topics/initial-block-download) path and brings a validating node +online much faster. ## Why fund it? @@ -45,7 +46,8 @@ messaging, and the BIPs needed to make multiple implementations interoperate. ## What's next? Recent work landed in [`utreexod` v0.5.0][v0-5-0] and [v0.5.1][v0-5-1]. -v0.5.0 added [SwiftSync-based][SwiftSync gist] proofless IBD and cut worst-case extra sync +v0.5.0 added [SwiftSync-based][SwiftSync gist] proofless +[IBD](/topics/initial-block-download) and cut worst-case extra sync bandwidth from about 1.4 TB to about 200 GB. It also pushed more of the protocol onto dedicated Utreexo messages and continued bridge-node and indexer work. v0.5.1 followed with a netsync fix. diff --git a/data/topics/assumeutxo.mdx b/data/topics/assumeutxo.mdx index 1d5f1c0fd..0e1dbee8e 100644 --- a/data/topics/assumeutxo.mdx +++ b/data/topics/assumeutxo.mdx @@ -5,11 +5,11 @@ category: 'Bitcoin' aliases: ['assume UTXO', 'UTXO snapshot'] --- -AssumeUTXO lets a new Bitcoin Core node load a snapshot of the UTXO set and begin sending and receiving coins right away, instead of replaying the entire chain from the genesis block before it can be used. The snapshot is identified by a hash that is compiled into the Bitcoin Core source, so the only trust is in the software the user is already running. +AssumeUTXO lets a new Bitcoin Core node load a snapshot of the [UTXO](/topics/utxo) set and begin sending and receiving coins right away, instead of replaying the entire chain from the genesis block before it can be used. The snapshot is identified by a hash that is compiled into the Bitcoin Core source, so the only trust is in the software the user is already running. After loading the snapshot, the node is immediately usable. In the background, it keeps verifying the full chain from genesis forward. If that background validation ever disagrees with the snapshot hash, the node shuts down and refuses to continue, so a bad snapshot cannot silently corrupt a wallet. -The feature cuts initial sync for a fresh node from days on a slow machine to minutes, without introducing a new trusted party. It landed in Bitcoin Core 27.0 and works alongside pruning. +The feature cuts [Initial Block Download](/topics/initial-block-download) for a fresh node from days on a slow machine to minutes, without introducing a new trusted party. It landed in Bitcoin Core 27.0 and works alongside pruning. ## References diff --git a/data/topics/bitcoin-node.mdx b/data/topics/bitcoin-node.mdx index 2e69933cb..2924a3930 100644 --- a/data/topics/bitcoin-node.mdx +++ b/data/topics/bitcoin-node.mdx @@ -14,6 +14,8 @@ Nodes can be packaged in different ways. Some are general-purpose implementation Wallets, Lightning apps, block explorers, mining software, and other services often depend on a node for trustworthy chain data and transaction broadcast. Many of those applications talk to the node through an [RPC](/topics/rpc) interface. Without enough people running their own nodes, more users end up relying on centralized infrastructure to tell them what Bitcoin says. +A fresh full node reaches the current chain tip through [Initial Block Download](/topics/initial-block-download), the sync process where it downloads and validates historical blocks before ordinary use. + ## References - [Running a full node](https://bitcoin.org/en/full-node) diff --git a/data/topics/initial-block-download.mdx b/data/topics/initial-block-download.mdx new file mode 100644 index 000000000..58f82188d --- /dev/null +++ b/data/topics/initial-block-download.mdx @@ -0,0 +1,35 @@ +--- +title: 'Initial Block Download' +summary: 'The first sync process where a Bitcoin full node downloads and validates the block chain from genesis to the current tip.' +category: 'Bitcoin' +aliases: ['IBD', 'initial sync', 'initial block sync'] +--- + +Initial Block Download (IBD) is the process a new [Bitcoin node](/topics/bitcoin-node) +goes through to synchronize with the rest of the network. The same term is used +when a node is far behind the current chain tip and needs to catch up. A fresh full +node starts from the hardcoded genesis block, finds peers, downloads block +headers and blocks, and validates the chain up to the best known tip. + +IBD is expensive because the node verifies historical proof of work, block +structure, transactions, scripts, and [UTXO](/topics/utxo) set changes as it +builds its local view of Bitcoin. The work is local validation, so the node +learns the current state by checking the chain itself instead of asking another +service what the valid chain is. + +During IBD, [Bitcoin Core](/projects/bitcoin-core) uses headers-first sync: it +downloads and partially validates the best header chain before fetching the +corresponding blocks from peers. A node in IBD can use significant bandwidth, +CPU, and disk I/O, and it usually delays normal wallet and +[mempool](/topics/mempool) behavior until it catches up. + +Much OpenSats-funded Bitcoin Core work touches IBD because faster, lighter sync +makes self-hosted validation practical on more hardware. Performance work, +pruning improvements, [AssumeUTXO](/topics/assumeutxo), and accumulator-based +approaches such as [Utreexo](/topics/utreexo) all relate to reducing the time, +storage, or resource cost of reaching the chain tip. + +## References + +- [Initial Block Download](https://developer.bitcoin.org/devguide/p2p_network.html#initial-block-download) +- [Running a full node](https://bitcoin.org/en/full-node#initial-block-downloadibd) diff --git a/data/topics/utreexo.mdx b/data/topics/utreexo.mdx index f096f70be..eef33e468 100644 --- a/data/topics/utreexo.mdx +++ b/data/topics/utreexo.mdx @@ -9,7 +9,7 @@ Utreexo is a proposed protocol for representing Bitcoin's [UTXO](/topics/utxo) s When a transaction spends a coin, the spender or a bridge node supplies an inclusion proof showing that the spent output is part of that committed set. A validating node can check the proof, update its accumulator, and keep enforcing Bitcoin's consensus rules without keeping the full UTXO set on disk. -This shifts some cost from local storage to extra proof data and bandwidth. The payoff is that fully validating compact-state nodes become practical on smaller machines, and sync strategies such as SwiftSync can parallelize more of the initial block download work. +This shifts some cost from local storage to extra proof data and bandwidth. The payoff is that fully validating compact-state nodes become practical on smaller machines, and sync strategies such as SwiftSync can parallelize more of the [Initial Block Download](/topics/initial-block-download) work. OpenSats has funded work on the protocol itself and on implementations built around it, including [utreexod](/projects/utreexod) and [Floresta](/projects/floresta). Draft BIPs now cover the accumulator format, validation rules, and P2P messages needed for interoperable implementations.