dergigi · Oct 16, 2026 · Oct 14, 2026 · Oct 14, 2026 · Oct 16, 2026
diff --git 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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.