Bitcoin Core Architecture

Mempool Graph Topology and the Ancestor Feerate Model

The Bitcoin mempool represents the distributed holding area for valid, unconfirmed transactions awaiting inclusion into the blockchain consensus ledger ¹. Formally, the memory pool operates as a directed acyclic graph (DAG), denoted as $G=(V,E)$ ². In this formulation, the vertex set $V$ corresponds to valid transactions admitted under standard node validation rules, and the directed edge set $E$ represents unspent transaction output (UTXO) spending dependencies ². When an unconfirmed transaction $t{x}_c\in V$ spends an outpoint created by another unconfirmed transaction $t{x}_p\in V$, a directed edge $(t{x}_p,t{x}_c)$ is instantiated, defining $t{x}_p$ as the parent (ancestor) and $t{x}_c$ as the child (descendant) ¹.

Topological ordering is a consensus invariant: no child transaction can appear in a block prior to its parent ¹. Therefore, candidate transaction selection by mining nodes cannot be executed as a naive, one-dimensional greedy knapsack optimization over individual transaction feerates ¹. The economic viability of confirming any given transaction is structurally coupled to the ancestor transactions that precede it ¹.

To account for these multi-transaction dependencies, Bitcoin Core historically implemented ancestor and descendant tracking within CTxMemPoolEntry objects ³. For any transaction $u\in V$, its ancestor set $\mathcal{A}(u)$ comprises $u$ along with the transitive closure of all unconfirmed parents ¹:

$$\mathcal{A}(u)=\{u\}\cup \{v\in V\mid \exists \text{ path from }v\text{ to }u\text{ in }G\}$$

The aggregate virtual size $\text{VSize}(\mathcal{A}(u))$ and cumulative modified fees $\text{Fee}(\mathcal{A}(u))$ establish the transaction’s Ancestor Feerate $R_A(u)$ ¹:

$$R_A(u)=\frac{{\sum }_{v\in \mathcal{A}(u)}\text{Fee}(v)}{{\sum }_{v\in \mathcal{A}(u)}\text{VSize}(v)}$$

To prevent high-feerate parent transactions from being artificially downgraded by low-feerate descendants during block construction, Bitcoin Core evaluates mining candidates using the ancestor score $S_A(u)=\min (R(u),R_A(u))$, where $R(u)=\frac{\text{Fee}(u)}{\text{VSize}(u)}$ denotes the individual transaction feerate ¹. This mathematical model enables Child-Pays-For-Parent (CPFP) fee bumping: a high-feerate child compensates miners for the block space occupied by its low-feerate unconfirmed ancestors ¹. For instance, given a parent transaction of $200\text{ vB}$ paying $400\text{ sats}$ ($2\text{ sat/vB}$) and a child transaction of $150\text{ vB}$ paying $2,100\text{ sats}$ ($14\text{ sat/vB}$), the ancestor feerate of the package evaluates to ¹:

$$R_A(t{x}_c)=\frac{400+2,100}{200+150}=\frac{2,500\text{ sats}}{350\text{ vB}}\approx 7.14\text{ sat/vB}$$

Under this valuation, an ancestor-aware block assembler mines the package atomically, capturing a combined yield that exceeds the parent’s individual feerate ¹.

Despite its utility, the legacy ancestor tracking architecture suffers from severe structural limitations ². Graph mutations (such as insertions, evictions, or block confirmations) require $\mathcal{O}(N)$ recursive tree traversals to update cached ancestor and descendant counters across connected subgraphs ³. Furthermore, an algorithmic asymmetry exists between block template assembly and mempool eviction ¹. While mining assembly prioritizes candidate subgraphs by descending ancestor feerate ($R_A$), eviction under memory exhaustion drops subgraphs by ascending descendant feerate ($R_D$) ¹:

$$R_D(u)=\frac{{\sum }_{w\in \mathcal{D}(u)}\text{Fee}(w)}{{\sum }_{w\in \mathcal{D}(u)}\text{VSize}(w)}$$

Because ancestor feerate and descendant feerate can rank identical transaction clusters in contradictory orders, transactions prioritized for block inclusion can simultaneously become targets for eviction during fee spikes, creating economic instability and complex pinning vulnerabilities ¹.

Cluster Mempool Theory and Linearization Algorithms

The Cluster Mempool framework replaces monolithic DAG traversal with modular decomposition, partitioning the global mempool graph $G$ into disjoint, connected components termed “clusters” ². Formally, a cluster $C\subseteq V$ is an isolated subgraph such that no vertex $u\in C$ shares an unconfirmed dependency edge with any vertex $v\in V\setminus C$ ². The fundamental objective of the cluster mempool architecture is to compute, cache, and update an optimal linearization for each independent cluster ².

A linearization $\mathcal{L}=(u_1,u_2,\dots ,u_m)$ is a permutation of all vertices in cluster $C$ that respects topological ordering: if $(u_i,u_j)\in E$, then $i<j$ ². A linearization ${\mathcal{L}}_a$ strictly dominates ${\mathcal{L}}_b$ (${\mathcal{L}}_a\succ {\mathcal{L}}_b$) if its feerate diagram is superior across all prefix sizes ⁴. The feerate diagram is the convex upper curve formed by plotting cumulative virtual size against cumulative fees across all ordered prefixes of $\mathcal{L}$ ⁴. An optimal linearization maximizes this curve, guaranteeing that selecting the first $k$ virtual bytes from the cluster yields the maximal achievable fee revenue for any topologically valid subset of equivalent size ⁴.

From an optimal linearization $\mathcal{L}$, the cluster is partitioned in linear time into a series of disjoint, contiguous sub-sequences termed “chunks” $\mathcal{C}=[c_1,c_2,\dots ,c_k]$ ². Each chunk represents a maximal-feerate prefix of the remaining sequence ². By mathematical definition, the chunk feerates within a cluster exhibit strict monotonic decay ²:

$$R(c_1)>R(c_2)>\cdots >R(c_k),\text{where }R(c_i)=\frac{{\sum }_{u\in c_i}\text{Fee}(u)}{{\sum }_{u\in c_i}\text{VSize}(u)}$$

Computing optimal linearizations on arbitrary directed graphs is equivalent to the maximum-weight closure problem under precedence constraints, which is NP-hard ⁴. Cluster Mempool overcomes this computational barrier through a multi-tiered optimization engine:

1. Size and Complexity Bounds: Node policy enforces strict limits on cluster size and topological complexity, preventing state-space explosions during real-time network validation loops ².
2. Branch-and-Bound Linearization: For small cluster topologies, an exhaustive branch-and-bound search evaluates all valid topological permutations to identify the provably optimal sequence ⁴.
3. Parametric Max-Flow / Min-Cut Network Optimization: For complex topologies, optimization is mapped to a parametric flow network using the Picard-Ratcliff theorem ⁴. Given a target feerate parameter $\lambda$, transactions are mapped to flow network vertices with source capacities $c(s,u)=\max (0,\text{Fee}(u)-\lambda \cdot \text{VSize}(u))$ and sink capacities $c(u,t)=\max (0,\lambda \cdot \text{VSize}(u)-\text{Fee}(u))$, with infinite capacity assigned to topological dependency edges ⁴. Applying push-relabel max-flow algorithms (such as the Goldberg-Tarjan framework) extracts minimum cuts that correspond directly to optimal prefix subsets at parameter $\lambda$ ⁴.
4. Post-Linearization Optimizations: Heuristic post-processing passes, including Linearization Merge Optimization (LIMO) and ancestor sort approximations, iteratively refine candidate sequences ⁴.

By pre-linearizing clusters into statically chunked sequences, Cluster Mempool establishes complete symmetry between block production and mempool eviction ¹. Block construction iterates across all clusters by selecting the highest-feerate available chunks, while mempool eviction pops the lowest-feerate chunks from the tail of the globally merged chunk index ¹. Furthermore, fee estimation models transition from tracking individual transaction confirmations to tracking chunk-level mining scores, eliminating distortion caused by unconfirmed parent-child dependencies ¹.

Anti-Pinning Policies, TRUC Transactions, and Package Relay Architecture

Standard mempool policy governs the boundary between unconfirmed peer-to-peer transaction propagation and consensus block production ³. In multi-party contract protocols, such as the Lightning Network, channel state transitions depend on the timely confirmation of pre-signed commitment transactions to enforce unilateral closes and resolve Hash Time Locked Contracts (HTLCs) before safety timeouts expire ⁵. In these adversarial environments, standard relay policies can be weaponized through transaction pinning, where an attacker exploits mempool acceptance rules to prevent a time-sensitive transaction from confirming ⁵.

Historically, unconfirmed replacements have been regulated by BIP 125 Opt-In Replace-By-Fee (RBF) ⁵. Under BIP 125, an incoming replacement transaction must pay an absolute fee greater than or equal to the aggregate sum of all transactions it would evict (Rule 3), and it cannot cause more than 100 existing transactions to be evicted from the mempool (Rule 5) ⁵. An adversary can exploit these rules by attaching a low-feerate, maximum-weight tree of descendants (up to the standard limit of 25 transactions and $101,000\text{ vB}$) to a shared commitment transaction ⁵. To replace this pinned package, the honest party is forced by Rule 3 to pay exorbitant absolute fees to offset the adversary’s large descendant chain, or is blocked entirely by Rule 5 if the descendant count threshold is saturated ⁵.

To eliminate structural pinning vectors, BIP 431 introduces Topologically Restricted Until Confirmation (TRUC) transactions, designated via version 3 transaction signaling (nVersion = 3) ⁵. TRUC enforces strict structural invariants on unconfirmed transaction subgraphs within the mempool:

1. The virtual size of an individual v3 transaction cannot exceed $10,000\text{ vB}$ ⁵.
2. An unconfirmed v3 transaction can have at most one unconfirmed parent transaction, and that parent must also be a v3 transaction ⁵.
3. An unconfirmed v3 transaction can have at most one unconfirmed child transaction (enforcing a strict 1-Parent-1-Child, or 1P1C, topology) ⁵.
4. The virtual size of the unconfirmed v3 child transaction cannot exceed $1,000\text{ vB}$ ⁵.
5. Non-v3 transactions cannot spend unconfirmed outputs of v3 transactions, preventing third parties from expanding the cluster topology ⁵.

By restricting the unconfirmed topology to a maximum of two transactions with an aggregate virtual size cap of $11,000\text{ vB}$, TRUC renders BIP 125 Rule 3 and Rule 5 pinning attacks mathematically impossible ⁵.

TRUC transactions operate alongside Pay-to-Anchor (P2A) outputs (OP_1 <0x4e73>), which establish standard, ephemeral anchor outputs ⁵. P2A outputs can be spent by any party without signature requirements, allowing Layer 2 implementations to deploy zero-fee commitment transactions that are dynamically fee-bumped at broadcast time via compact 1P1C child packages ⁵.

To propagate zero-fee or sub-relay-fee parent transactions that depend entirely on high-fee child packages, the peer-to-peer network implements BIP 331 Ancestor Package Relay ⁶. BIP 331 replaces isolated transaction broadcasts with package negotiation messages (sendpackages, pkgtxns, ancpkginfo) ⁶. When a node receives a child transaction referencing an unknown parent outpoint, it queries the peer for the ancestor package rather than dropping the transaction as an orphan ⁶. The validation engine processes the package atomically using ProcessNewPackage and AcceptPackage, verifying that the aggregate package feerate meets standard mempool admission criteria ⁶:

$$R_{\text{pkg}}=\frac{{\sum }_{tx\in \mathcal{P}}\text{Fee}(tx)}{{\sum }_{tx\in \mathcal{P}}\text{VSize}(tx)}\ge \text{minRelayTxFee}$$

This mechanism ensures that transactions below individual dynamic relay thresholds can safely enter the mempool DAG if the net package feerate satisfies standard eviction and relay policies ⁶.

Block Assembly Mechanics and BlockTemplateManager Engine

The construction of candidate block templates is executed by the BlockAssembler class within src/node/miner.cpp ¹. The primary objective of BlockAssembler is to solve a multi-dimensional knapsack optimization problem: selecting a subset of transactions from the mempool DAG that maximizes fee revenue while adhering strictly to consensus constraints ¹. These limits comprise a maximum block weight of $4,000,000\text{ Weight Units}$ (WU), equivalent to $1,000,000\text{ vB}$, and a maximum execution budget of $80,000\text{ SigOp Cost Units}$ to prevent signature validation denial-of-service attacks ¹.

Block template generation begins in BlockAssembler::CreateNewBlock, which initializes the block header fields, constructs the placeholder coinbase transaction, and allocates consensus overhead margins ¹. The assembler then enters its selection loop within BlockAssembler::addPackageTxs ¹. In the legacy model, this loop queries a priority queue of mempool entries sorted by ancestor feerate via CompareTxMemPoolEntryByAncestorFee ¹.

When a high-scoring transaction $t{x}_{\text{target}}$ is evaluated, the assembler extracts its full unconfirmed ancestor set $\mathcal{A}(t{x}_{\text{target}})$, filters out any transactions already committed to the current template, and verifies that the remaining package satisfies both the residual block weight and SigOp limits ¹. If the package fits, the transactions are appended to the template in topological order, and the cached ancestor values of remaining mempool transactions are updated to reflect the inclusion of those ancestors ¹. Under Cluster Mempool, this iterative re-indexing loop is replaced by sequential chunk extraction: BlockAssembler walks the global list of pre-linearized clusters in descending order of chunk feerate, appending each chunk directly to the block template until consensus limits are reached ¹.

To support high-throughput mining infrastructure without introducing RPC latency into block construction, Bitcoin Core provides the BlockTemplateManager subsystem ⁷. Rather than assembling a new block template on every incoming RPC request (such as getblocktemplate), BlockTemplateManager maintains an asynchronous cache of pre-assembled templates synchronized directly with mempool state updates ⁷.

BlockTemplateManager subscribes to BlockConnected notifications from the validation interface to invalidate and clear stale template caches whenever the chain tip advances ⁷. It coordinates block production across multiple internal subsystems:

1. Mining RPC interfaces serving external pool infrastructure (getblocktemplate, waitNext, createNewBlock) ⁷.
2. The Peer Manager, which requires immediate template references to generate Compact Block short ID filters ⁸.
3. Mempool fee estimation forecasters that continuously evaluate candidate block space demand to project feerate percentiles ⁷.

Mining Protocol Modernization: Stratum v2 and Decentralized Template Selection

The block template produced by a full node establishes the candidate ledger state, but the distribution of that template across physical mining hardware is governed by dedicated mining communication protocols ⁹. Historically, pooled mining relied on the getwork and getblocktemplate (GBT) protocols before standardizing on Stratum v1 ⁹. Stratum v1 utilizes cleartext JSON-RPC framing to coordinate work between pool servers and individual ASIC mining devices ⁹.

Stratum v1 introduces a significant centralization vector into the network architecture ⁹. In Stratum v1, the pool’s central server constructs the block template, inserts its own coinbase transaction, builds the Merkle tree, and transmits only the raw 80-byte header components along with Merkle branches to individual hashing workers ⁹. The physical mining devices remain entirely unaware of the specific transactions included in the block they are computing proof-of-work for ⁹. Consequently, pool operators retain centralized authority over transaction selection, policy enforcement, and transaction censorship, while individual miners are unable to audit or modify the block contents ⁹.

Stratum v2 (SV2), implemented via the Stratum Reference Implementation (SRI), re-architects pooled mining by decoupling hashrate aggregation from transaction selection authority ⁹. SV2 replaces cleartext JSON-RPC strings with an encrypted, binary-framed protocol utilizing Authenticated Encryption with Associated Data (AEAD), reducing bandwidth consumption while eliminating man-in-the-middle hashrate hijacking risks ⁹.

The core architectural innovation of Stratum v2 is the Job Negotiation sub-protocol, which operates through four primary components ⁹:

1. Template Provider (TP): A local subsystem running alongside a full Bitcoin Core node (bitcoind) that builds custom block templates directly from the local mempool via BlockAssembler ⁹.
2. Job Negotiator (JN): A client component operated by the miner that negotiates custom block templates with the mining pool ⁹.
3. Pool Job Negotiator Server: The pool-side interface that evaluates custom templates proposed by miners against pool fee policies and validity rules ⁹.
4. Mining Devices: Downstream ASIC hardware units that compute proof-of-work on work packages assigned by the local Job Negotiator ⁹.

In this workflow, the miner’s Template Provider constructs a candidate block template and forwards the transaction set and Merkle path to the local Job Negotiator ⁹. The Job Negotiator transmits a proposal token containing the candidate Merkle root to the pool’s Job Negotiator server ⁹. The pool validates the proposed template against its operational parameters and returns a signed job token, allowing the miner’s hashing hardware to mine on the locally constructed block template ⁹. If the pool rejects the proposal, the Job Negotiator can automatically fall back to alternative pools or transition to solo mining ⁹. This protocol design returns transaction selection authority to individual hashers, mitigating the threat of pool-level transaction censorship ⁹.

Consensus Validation and Chain Propagation Pipelines

When a miner finds a valid proof-of-work nonce for a candidate block header, the block is broadcast to the peer-to-peer network, transitioning the contained transactions from unconfirmed mempool states to immutable consensus ledger state ¹.

Consensus state transitions within Bitcoin Core are coordinated by ChainstateManager and executed through ConnectBlock ⁷. Structural block verification follows a strict sequence:

1. Header Validation: CheckBlockHeader verifies proof-of-work difficulty targets against the block header hash, checks that timestamps remain within acceptable bounds, and enforces the Median-Time-Past (MTP) rule ¹.
2. Contextual Validation: CheckBlock validates that the computed Merkle root matches the header commitment, enforces block weight limits ($4,000,000\text{ WU}$), checks the Segregated Witness commitment in the coinbase script, and verifies that the block’s transactions are topologically ordered ¹.
3. State Transition Execution: ConnectBlock applies the state transition function against the active UTXO view (CoinsViewCache), ensuring all referenced inputs exist, checking input values against output values to prevent inflation, verifying coinbase maturity limits (100 blocks), executing script verification scripts (ECDSA, Schnorr, Tapscript) via parallel CScriptCheck worker threads, and pruning confirmed transactions from the active mempool DAG ³.

The UTXO database mutation for block $B$ at height $h$ is expressed formally as:

$${\text{UTXO}}_h=\left({\text{UTXO}}_{h-1}\setminus \bigcup _{tx\in B}\text{Inputs}(tx)\right)\cup \bigcup _{tx\in B}\text{Outputs}(tx)$$

To accelerate block relay across the network and minimize orphan rates caused by propagation latency, Bitcoin nodes implement BIP 152 Compact Blocks ⁸. Rather than transmitting full, multi-megabyte block payloads containing transactions that already reside in recipient mempools, BIP 152 constructs a compact HeaderAndShortIDs payload ⁸. This message contains the 80-byte block header, the full coinbase transaction, and an array of 6-byte truncated Short IDs for each non-coinbase transaction ⁸.

These 6-byte Short IDs are computed using a SipHash-2-4 construction seeded by the block header nonce and outpoint salt ⁸. Upon receiving a compact block, the node cross-matches the Short IDs against its local mempool transactions ⁸. In High-Bandwidth Mode, if all Short IDs resolve to known mempool transactions, the node reconstructs and validates the full block immediately, eliminating network round-trip delays ⁸. If any Short IDs cannot be matched due to mempool differences, the node transmits a getblocktxn request for the missing transaction indices and reconstructs the block upon receiving the corresponding blocktxn payload ⁸.

To streamline node synchronization, Bitcoin Core provides the AssumeUTXO framework (introduced in Bitcoin Core 26.0) ¹⁰. Historically, Initial Block Download (IBD) required sequential, computationally intensive script verification from the genesis block before a node could participate in active validation ¹⁰. AssumeUTXO decouples initial bootstrap time from historical ledger replay using the loadtxoutset RPC command, which imports a serialized snapshot of the UTXO set at a hardcoded base height ($Bas{e}_h$) ¹⁰.

ChainstateManager initializes two concurrent chainstate engines ¹⁰:

1. Snapshot Chainstate: Loads the confirmed UTXO snapshot directly into the active validation engine, allowing the node to immediately track the active chain tip, process incoming blocks via Compact Blocks, populate its mempool, and serve mining templates ¹⁰.
2. Background Chainstate: Concurrently validates historical blocks from the genesis block up to $Bas{e}_h$ in the background, executing full script verification ¹⁰.

When the background validation engine reaches $Bas{e}_h$, it computes the SHA-256 hash of the reconstructed UTXO state and verifies it against the snapshot’s cryptographic commitment ¹⁰. Upon verification, the background chainstate is pruned, establishing a unified ledger state and transitioning the node to standard operation without requiring sync-time downtime ¹⁰.

Architectural Synthesis

The lifecycle of a Bitcoin transaction forms a continuous progression across distinct subsystem layers:

1. Mempool Ingestion and Topology Optimization: Standard transactions enter the peer-to-peer mempool, where they are partitioned into isolated topological clusters ². Parametric max-flow/min-cut algorithms establish optimal linearizations, partitioning each cluster into monotonically decreasing feerate chunks ⁴. Anti-pinning standards (BIP 431 TRUC/v3) and BIP 331 Ancestor Package Relay protect these graph topologies from resource-exhaustion attacks, ensuring accurate valuation for multi-party contract transactions [^4, ^5].
2. Block Template Construction: The BlockAssembler consumes these pre-linearized chunks to construct revenue-maximizing candidate blocks that respect consensus weight and SigOp limits ¹. The BlockTemplateManager coordinates template caching across mining interfaces and peer managers ⁷. Stratum v2 protocols distribute this template construction process directly to individual miners, preventing the concentration of transaction selection authority in centralized pool operators ⁹.
3. Consensus State Execution and Propagation: Once solved, blocks propagate across the network using BIP 152 Compact Blocks, resolving short transaction identifiers against local mempool state ⁸. ChainstateManager applies these block state transitions to mutate the UTXO database, invalidates confirmed entries from the mempool DAG, and utilizes AssumeUTXO snapshot validation to support rapid node deployment [^8, ^10].

These interconnected subsystems operate in concert, aligning transaction relay policies, economic incentive models, and cryptographic consensus validation into a unified distributed ledger architecture.

Works Cited

1. Bitcoin Core Contributors, “Ancestor Feerate and Package Mining in Bitcoin Core”, 2016 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30 ↩31 ↩32 ↩33 ↩34 ↩35 ↩36 ↩37

2. Suhas Daftuar, “Cluster Mempool Definitions and Theory”, 2023 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15

3. Bitcoin Core Reviews, “Cluster Mempool PR Review Club #31363”, 2024 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

4. Pieter Wuille, “How to Linearize Your Cluster”, 2023 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

5. Greg Sanders, “BIP 431: Topologically Restricted Until Confirmation (TRUC)”, 2024 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20

6. Gloria Zhao, “BIP 331: Ancestor Package Relay”, 2022 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

7. Bitcoin Core Developers, “BlockTemplateManager Architecture and Template Caching”, 2024 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

8. Matt Corallo, “BIP 152: Compact Block Relay”, 2016 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

9. Stratum Protocol Community, “Stratum V2 Protocol Specification and SRI Architecture”, 2023 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30

10. James O’Beirne, “AssumeUTXO: Fast Node Synchronization via UTXO Set Snapshots”, 2023 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18