1. Introduction
Bitcoin cryptocurrency and the blockchain concept were introduced in [
1], where the protocol is supported by a linear chain. Motivated by questions of enhancing the scalability and security of linear chain Bitcoin, we introduce the D-BTC (Domino Bitcoin) protocol, supported by a simply connected two-dimensional structure. The blocks, called B-dominoes (Bitcoin dominoes) are organized as a finite connected region subset of
without holes, also called a lattice (see
Figure 1 and
Figure 2 below). Simple connectivity plays a central role in D-BTC and to mine a (valid) B-domino, a miner has to compute four PoWs (Proofs of Work), corresponding to cardinal directions, allowing them to add it to the frontier of the lattice, under the constraint that the new lattice is simply connected.
As well as standard information in the heading of a B-domino, we include its position in the lattice, and four independent nonces (numbers used once) for proofs of work. Furthermore, we introduce a new deterministic consensus, based roughly on the maximization of the lattice surface.
In this paper, we are interested in the following problem. Linear chain blockchains face two structural limitations: (i) Throughput: with one block mined sequentially, the maximum throughput is upper-bounded by a constant, regardless of the network size. Bitcoin operates near 7 TPS and Ethereum near 15 TPS—both far below the demand of real-world payment systems. (ii) Finality: under the honest majority assumption (where the adversary controls of total hash power), the Nakamoto heuristic gives a reversal probability that decreases in the confirmation depth k. Achieving a reversal probability at requires roughly confirmations.
Some existing partial answers are as follows. DAG-based architectures (Tangle [
2], PHANTOM [
3]) increase throughput by allowing concurrent block production on a directed acyclic graph. However, they introduce non-trivial ordering and weight algorithms. Sharding solutions (OmniLedger [
4], Elastico [
5]) partition the network into parallel chains but require complex cross-shard protocols.
Can the linear topology of Bitcoin be replaced by a richer geometric structure that simultaneously (i) enlarges the number of valid positions where parallel mining can occur, and (ii) strengthens the asymptotic decay of the double-spend reversal probability, without recourse to sharding, DAG ordering algorithms, or trusted committees? We answer this question affirmatively by constructing D-BTC, which is two-dimensional, allowing parallel block production on distinct positions of the structure.
In this work, we emphasize the use of the following techniques. A discrete version of isoperimetric inequality (see [
6], p. 284) enabling to increase the number of valid positions where miners can add B-dominoes. We use Nakamoto’s analysis and a reduction argument to estimate the reversal probability for double-spending attacks. As for implementation and tests, fast standard algorithms are used in the processes of mining and (locally) verifying simple connectivity of the ledger such as: depth-first search (DFS), breadth-first search (BFS), and flood-fill algorithms.
Our key contributions include:
- 1.
Complete D-BTC protocol specification with four-directional PoW (N, S, E, W) and simple connectivity constraint;
- 2.
Formal proofs for all fundamental results;
- 3.
Mining and validation algorithms with proven correctness;
- 4.
Surface-based consensus mechanism with deterministic fork resolution;
- 5.
Security analysis with formally proven quadratic attack cost;
- 6.
An implementation with performance analysis.
The paper is organized as follows.
Section 2 reviews related works.
Section 3 presents the protocol specification.
Section 4 provides the fundamental properties of the D-BTC protocol.
Section 5 analyzes security properties.
Section 6 discusses an implementation and performances.
Section 7 presents our experimental setup and some tests of D-BTC for validation.
Section 8 concludes the paper with future research directions. Throughout this paper, the symbol □ indicates the end of a proof.
4. Some Properties of the D-BTC Protocol
This section provides some fundamental properties of the D-BTC protocol.
4.1. Non-Blocking Property
We assume that the constraint
always admits a solution for a cryptographic hash function
H (see Equation (
6)). The following proposition is intuitively clear; it hints at the possibility that the D-BTC protocol tiles the plane
given the assumption above. However, concerning domino systems, the set of tiles is not known a priori (see
Section 2.5).
Proposition 1 (Non-Blocking Progression). For any finite simply connected lattice with , the frontier is non-empty: .
Proof. We prove by construction that at least one valid frontier position always exists.
Step 1: Existence of extremal point. Since
is finite and non-empty, define:
Let
. The point
exists and is in
.
Step 2: Candidate frontier position. Consider . We show .
Step 3: Adjacency verification. By construction,
is 4-adjacent to
since:
Step 4: Simple connectivity preservation. Let . We verify both conditions:
(a) Path-connectivity: For any , there exists a path from q to (since is connected). Extending this path by one step to gives connectivity to . Thus, is path-connected.
(b) No holes: Assume for contradiction that contains a hole . Since had no holes, H must involve in its boundary. But is at the rightmost extent of (at ), so no point can be enclosed to the right of . For H to be enclosed, it must be bounded on all four sides by . However, positions for any y are in and connected to infinity, so they cannot be part of a hole. Thus, any empty position near connects to the exterior, contradicting the existence of hole H.
Conclusion: , hence . □
Corollary 1
(Protocol Liveness). The D-BTC protocol cannot deadlock—miners can always find valid positions to extend the lattice by a valid B-domino.
Proof. Direct consequence of the proposition. □
4.2. Frontier Size Analysis
A polyomino, in this work, is a finite simply connected set of cells (or elements of ). Thus, valid ledgers of D-BTC are polyominoes. For a ledger , we denote by its boundary consisting of the set of cells in having an edge in , and we set called the perimeter of
We recall the classical isoperimetric inequality in the plane (see [
6]): for the length
L of a closed plane curve and the area
A of the region that it encloses, we have
and that equality holds if and only if the curve is a circle. In the following, we mainly adapt the isoperimetric inequality to polyominoes to get convenient bounds. With regard to end implementations, we also introduce the notion of compact lattices.
Lemma 1 (Perimeter Lower Bound)
. For any simply connected region with , the perimeter satisfies:where, for a real x, denotes the least integer greater or equal to Proof. Apply the isoperimetric inequality (
14) adapted to our case. □
Proposition 2 (Frontier Size Bounds)
. For a simply connected lattice with blocks, there is a constant such that the frontier size satisfies: Proof. For the lower bound, by Lemma 1, the perimeter has at least edges. Then, note that each element of the frontier of corresponds to at most 3 elements of the boundary
For the upper bound, note that each block can contribute at most 4 frontier positions (one per direction). A single-block lattice has exactly 4 frontier positions. For n blocks in a line (worst case for perimeter), the frontier size is (top, bottom, plus two ends). □
We define a compact lattice
(see
Figure 4) as a lattice such that
which is convenient for our implementation (see
Section 6 and
Section 7). It was observed [
26] that for a given size
a minimal-perimeter polyomino is very loosely a square. With 10,000 blocks, roughly 400 frontier positions are available simultaneously—compared to exactly 1 in Bitcoin. Thus, it is advantageous to maintain a compact lattice structure.
4.3. Verification Complexity
Proposition 3 (Connectivity Verification Complexity). Algorithm 2 verifies simple connectivity in time, where A is the bounding box area. For compact lattices with n blocks, this is .
Proof. Step 1 (BFS/DFS): Traverses each block once: . Step 2 (Neighbor check): Checks 4 neighbors of candidate: . For the optimized local check (as implemented): only immediate neighbors are verified for potential enclosure, giving per check.This gives a total of for full verification, for local hole detection. □
4.4. Mining Complexity
In the following, we suppose that H has length 256 and the same difficulty in all directions. The present formulation of the next result is convenient, as suggested by Remark 3.
Proposition 4 (Expected Mining Time)
. Let d be the difficulty parameter such that . The expected number of hash computations to mine a B-domino with four independent directional constraints is:when mining all four directions sequentially with full independence and the same difficulty. Proof. Each PoW constraint is satisfied independently with probability
. In the sequential mining approach (as implemented), each direction is mined independently:
For four directions mined sequentially, total expected attempts:
However, the effective difficulty when all four constraints must be simultaneously valid for block acceptance means the work factor is multiplicative in terms of security:
□
For typical frontier positions, mining requires quadratically more work than single-constraint linear mining per effective security unit.
4.5. Consensus Uniqueness
Proposition 5 (Deterministic Consensus). Given two valid simply connected lattices and with , there exists a unique canonical lattice .
Proof. The surface-based consensus rule provides a total ordering on valid lattices. Since by assumption, exactly one of has maximum PoW.
For equal PoW values, which is negligible when the size , a deterministic tie-breaker based on the lexicographic ordering of block hashes ensures uniqueness. □
4.6. Hole Prevention
Proposition 6 (Hole Creation Conditions). Adding position to lattice creates a hole if and only if there exists a finite non-empty set such that every position in H is surrounded by .
Proof. Forward direction: Suppose adding p creates a hole. By Definition 4, the complement has more than one connected component. Since one component is infinite (extending to infinity in ), there must exist at least one finite component H. Every position in H cannot reach infinity, thus is surrounded.
Reverse direction: If such H exists, then H forms a finite connected component of the complement separate from the infinite exterior. Thus, the complement has at least two components, violating simple connectivity. □
Remark 5. The minimum number of blocks required to enclose a single-cell hole is 4, achieved by surrounding a position on all four sides. Also, to create a hole H, requires elements of
6. Implementation and Performance
In this section, we describe the implementation methodology, a rough comparison with other blockchains, and some performance results based on the first part of this work.
6.1. Reference Implementation
We have developed a complete reference implementation of D-BTC Testnet with the following features:
- 1.
Full 4-Directional PoW: All four nonces (N, S, E, W) must satisfy their respective constraints;
- 2.
Complete Merkle Tree: With inclusion proofs and verification;
- 3.
Surface-Based Consensus: ;
- 4.
Zone-Based Mining: Blocks assigned to zones (NE, NW, SW, SE) based on position.
Table 1 summarizes the computational complexity of key operations of this implementation.
6.2. Parallelization Analysis and Frontier Size Validation
With frontier positions, miners can work simultaneously on distinct positions without conflict. Indeed, each frontier position is independent: mining at does not affect the validity of mining at (both can succeed). With by Proposition 2, up to miners can work in parallel. Thus, the mining capacity is enhanced.
Figure 7 shows the experimental validation of frontier size predictions. The measured frontier sizes closely match the theoretical prediction
for compact lattice growth; see Equation (
16) of Proposition 2 with K = 1.
6.3. Gossip Protocol Configuration
The implementation uses an authentic gossip protocol with:
Fanout: 3 peers per message forwarding;
TTL (Time-to-Live): 10 maximum hops;
Message cache: 10,000 seen message IDs for deduplication;
Heartbeat: 10 s interval for liveness.
Message types include: BLOCK, TRANSACTION, PEER_ANNOUNCE, SYNC_REQUEST, SYNC_RESPONSE, HEARTBEAT, and FULL_SYNC. D-BTC uses an epidemic gossip protocol for message propagation. Rather than flooding every peer with every message, each node forwards received messages to a random subset of its peers (the “fanout”), with a time-to-live (TTL) counter that decrements at each hop.
It is easy to verify that with fanout f and TTL , a single message reaches up to nodes. For our implementation, we set (, ): .
Messages are deduplicated through a least recently used cache of message IDs (MESSAGE_CACHE_SIZE = 100,000). When a message arrives, its ID is checked against the cache; if already seen, it is silently dropped. This ensures each message is processed at most once per node, bounding bandwidth usage regardless of network topology.
Table 2 compares D-BTC with existing architectures; see
Section 2, DAG-based Architectures for references.
7. Experimental Setup, Tests, and Validation
To validate the theoretical predictions, we conducted three independent experiments on a 4-node P2P network. We conduct three experiments (also called benchmarks) for testing. Each benchmark ran the complete D-BTC stack: four mining nodes with exclusive zone assignments, sixteen wallets generating inter-node transfers, gossip-based propagation, and automatic synchronization. The testnet configuration is summarized in
Table 3.
Three benchmarks were run sequentially rather than in parallel, ensuring that each benchmark started from a fresh state while benefiting from the accumulated lattice of prior runs. This approach tests both cold-start behavior (Benchmark 1) and warm-start dynamics (Benchmarks 2 and 3).
7.1. Mining Performance
Table 4 presents the aggregate results across all three benchmarks. The system mined a total of 18,786 blocks in 726.7 s of combined runtime.
The mean throughput of 10.25 blocks/second (coefficient of variation: 15.5%) is noteworthy for a testnet with difficulty . In a production setting with higher difficulty, the throughput would decrease but the security per block would increase proportionally.
Figure 8 shows the detailed mining dynamics from Benchmark 3, which produced the highest block count. The block growth curve (panel a) is strikingly linear, indicating steady-state mining. The frontier evolution (panel b) tracks the theoretical prediction
closely. The zone distribution is near
balance.
7.2. Frontier Growth Validation
The central theoretical prediction of this paper is that the frontier grows as
. To test this rigorously, we performed regression analysis on all three benchmarks.
Table 5 presents the regression results across the three benchmarks.
The average
means that 98.96% of the variance in frontier size is explained by the
model.
Figure 9 presents the most visually compelling evidence: the measured frontier (red dots) lies almost perfectly on the theoretical curve (blue line), and the percentage deviation (panel b) remains within
for the vast majority of the measurement window.
The slight decrease in from Benchmark 1 (0.9959) to Benchmark 3 (0.9808) is expected: as the lattice grows larger, boundary effects from the rectangular testnet topology become more pronounced, causing small deviations from the idealized diamond shape. Importantly, all three values remain above 0.98—an excellent fit by any standard.
7.3. Zone Distribution
Table 6 reports the zone distribution and
uniformity tests for each benchmark. All three benchmarks pass the
uniformity test at 95% confidence (
with 3 d.f.). The largest deviation from the expected 25% is only 0.54% (NE zone in Benchmark 1), and the zone balance improves with lattice size—Benchmark 3’s maximum deviation is just 0.23%. This demonstrates that the exclusive zone mining mechanism works as intended.
7.4. Transaction Processing
Table 7 summarizes the transaction processing results across all benchmarks. Across all three benchmarks, 5312 transactions were submitted and every single one was confirmed, yielding a 100% confirmation rate.
Figure 10 provides a detailed view from Benchmark 3.
The average confirmation time of 47.63 s deserves interpretation. Unlike Bitcoin, where the confirmation time reflects the block interval (10 min on average), D-BTC’s confirmation time is determined by how quickly a pending transaction is included in a mined block. The near-uniform distribution between 0 and 90 s suggests that transactions enter the mempool (memory pool) at random times relative to the block production cycle, which is consistent with a well-functioning system.
7.5. Security Analysis Revisited and Numerical Comparison
We give more comparisons concerning the reversal probabilities of Bitcoin and D-BTC based on Equations (
26) and (
27) of
Section 5 assuming an honest majority. The advantage of D-BTC over Bitcoin is the transition from linear to quadratic decay in reversal probability.
Table 8 and
Figure 11 quantify this advantage for
, a commonly studied attack threshold.
The headline result in
Table 8: six D-BTC confirmations provide security equivalent to 36 Bitcoin confirmations. At
, D-BTC achieves a reversal probability of
, which is
times smaller than Bitcoin’s
.
7.6. Consolidated Validation
As a conclusion of these tests,
Table 9 provides a complete mapping between theoretical claims made in this paper and the experimental evidence supporting it.
Table 10 combines the statistics of the three benchmarks.
Remark 7 (Limitations and extensions)
. The current testnet operates at low difficulty () and small node count () by design, prioritizing theoretical validation over production-scale performance. All three benchmarks confirm the isoperimetric prediction (Table 5, ), the 100% transaction confirmation rate (Table 7), and the absence of structural forks across 18,786 mined blocks. Towards a practical scaled proposal, we must vary the parameters such as K and target difficulty .We emphasize that the key theoretical predictions are scale-invariant by construction: Proposition 2 holds for any n, and Proposition 9 depends only on the confirmation depth k, not the absolute lattice size. Larger-scale experiments will primarily test the engineering behavior (gossip delays, memory management, fork resolution latency) rather than the mathematical predictions, which are established by proof.
8. Conclusions
We have shown that the D-BTC protocol has the potential to improve scalability and at the same time to enhance security. This is due to the introduction of geometric and topological notions in the realm of blockchains.
The main results are: (i) the four-directional PoW structure (Definition 6) cryptographically links each B-domino to its four cardinal neighbours; (ii) the simple connectivity invariant (Definition 4, Algorithm 2) prevents partition attacks by construction (Proposition 7) and enables deterministic fork resolution (Proposition 5); (iii) the discrete isoperimetric inequality (Lemma 1) yields a frontier of size (Proposition 2), enabling approximately miners to work in parallel without sharding; (iv) the surface-based consensus provides a total ordering on valid lattices; and (v) the reduction argument establishes that the double-spend reversal probability decays as (Proposition 9).
Some directions for future research are suggested, for example:
- 1.
Adaptation of D-BTC to higher dimensions; again, isoperimetric inequalities will play a central role.
- 2.
Adaptation to other consensus such as proof of stake, or hybridization of consensuses.
- 3.
Impact of other attacks such as selfish mining [
10].
- 4.
The zone-assignment strategy for miners in our tests is somewhat limited. It is possible to avoid this by using advanced hashing techniques.
- 5.
Computation of maximum transaction production per unit of time.
- 6.
More in-depth security analysis following the works of [
27,
28,
29], including a native two-dimensional finality proof based on competing growth processes on
under the simply connected constraint. Such an analysis would provide a self-contained 2D stochastic bound, strengthening the reduction argument of
Section 5.4.
- 7.
Integration of Smart Contracts.