Clanker Coin: a deterministic proof-of-work currency for people and machines

00Abstract

Clanker Coin is an independent proof-of-work cryptocurrency whose consensus is a pure function of integers. Every rule a node applies, from the hash that secures a block to the schedule that issues a coin, is specified in fixed-width integer arithmetic with no floating point, no vendor behaviour, and no privileged key, so that any implementation on any hardware reaches the same answer from the same bytes. The chain targets a 30-second block interval for payments, a fixed issuance of 420,479,999 CLKC, and an unspent-output ledger in which validation parallelises and reorganisations are mechanical. Blocks are secured by ClankerHash, a memory-hard function built from BLAKE3 that fills a 64 KiB scratchpad and mixes it through 1,024 dependent rounds; it is designed to run efficiently on commodity GPUs and to be verified cheaply by a full node, and it makes no claim of ASIC resistance. This paper states the model, gives the mathematics of the proof of work, the difficulty controller, chain work, timekeeping, issuance, transactions, and settlement, and derives the resource budget a node operator commits to. It closes with the research programme the currency was built for: an economy that people and autonomous software use on identical terms.

01Introduction

A proof-of-work currency is a contract written in arithmetic. Its holders are protected not by an institution but by the fact that every participant, given the same history, computes the same state. That guarantee is only as strong as the determinism of the rules: a rounding mode that differs between two processors, a hash that differs between two GPU drivers, or a clock that a peer can move, is a fork waiting to happen. Clanker Coin was designed from that observation outward. Where a rule could be expressed as a shift, a compare, or a checked integer sum, it was; where a design was more elegant but needed a transcendental function or a lookup table, the elegance lost.

The second design pressure is the block interval. At 30 seconds, propagation delay is a large fraction of the interval, so competing blocks at the same height are routine rather than exceptional [9]. Everything downstream is built to treat a one-block reorganisation as ordinary: fork choice measures work rather than height, the ledger is undone from explicit undo data, and merchants are given confirmation guidance sized to the value at risk rather than a promise of finality.

The third is honesty about hardware. ClankerHash is built to make ordinary graphics processors an efficient first platform, and the reference implementation is the CPU verifier every backend must match byte for byte. No proof of work can promise permanent resistance to special-purpose silicon, and this one does not try; instead the mining protocol is open to any device that can pass the frozen conformance vectors.

Sections 02 through 11 present the protocol in the order a node validates it: the ledger model, the proof of work, the difficulty controller, chain work, time, issuance, transactions, settlement, the resource budget, and the mining interface. Section 12 describes the research question that motivated the chain. Throughout, ${\mathrm{B3}}_{256}$ denotes BLAKE3 with a 32-byte output [2], $\mathrm{B3-XOF}$ its extendable output, and $\parallel$ concatenation of byte strings. Every hash in the protocol is prefixed by an ASCII domain string, written here in monospace, so that a value valid in one context can never be replayed in another.

02The ledger

The state of the chain after block $h$ is a set $S_h$ of unspent transaction outputs. Each output is a pair $\left(v,\ell \right)$ of a value $v$ in clanks, an integer with $1\le v\le \mathrm{MAX\_MONEY}$, and a locking program $\ell$. A transaction consumes outputs and creates outputs; a block $B_h$ is an ordered list of transactions whose first element is the coinbase. The transition is

where $\mathrm{In}\left(B\right)$ is the set of outputs the block spends and $\mathrm{Out}\left(B\right)$ the set it creates. A block is valid only if every consumed output exists in $S_{h-1}$ or was created earlier in the same block, no output is consumed twice, and every input carries a witness that satisfies the program of the output it spends (section 08). For every non-coinbase transaction, value is conserved with a non-negative remainder that becomes the fee:

The coinbase has no inputs. Its outputs are bounded by the subsidy of the height (section 07) plus the fees of the block it seals:

The inequality is deliberate. A miner that pays itself less has produced a valid block and destroyed the difference; a miner that pays itself more has produced an invalid one. This turns a bug in mining software into a loss for one miner rather than a fork for the network.

Three properties of this model carry the rest of the design. Validation of a transaction is a pure function of the transaction and the outputs it spends, so independent transactions verify in parallel with no shared mutable state, which matters at a short block interval. Undoing a block is restoring the outputs it consumed from undo data, not replaying execution, so a reorganisation is mechanical. And a merchant watching for a payment assigns a fresh locking program per invoice and waits for an output to appear at it; no balance arithmetic and no notion of sender identity is needed.

Every sum in equations (2) and (3) is computed with checked addition in an unsigned 64-bit integer, every amount is range-checked before use, and an overflow is a validation failure rather than a wrap. Decoders are total functions: every count and length is checked against a consensus limit before any allocation, and a byte string that does not decode to exactly one object is rejected.

03ClankerHash

A block header is a fixed 152-byte structure: version fields, the network identifier, the height, the parent’s block id, the Merkle root, the timestamp, the target, a 64-bit nonce, a 64-bit extra nonce, and sixteen reserved zero bytes. The proof-of-work rule is the comparison of two 256-bit integers, the digest interpreted big-endian and the target $T$ carried in the header:

The target itself is not chosen by the miner. A node recomputes the expected target for the height from the chain (section 04) and rejects a header whose target differs, so a miner cannot make its own work easier. What follows is the function on the left of (4), whose six stages Figure 1 summarises.

Seed. The header is reduced once to a 32-byte seed. Because the seed covers every header field, any change to the nonce, the extra nonce, the Merkle root, the timestamp, the parent, the height, or the target produces an unrelated seed and therefore an unrelated scratchpad.

Scratchpad and state. Two extendable-output calls expand the seed into a 64 KiB scratchpad, read as 1,024 lines of 64 bytes, and a 64-byte working state:

A GPU may produce the XOF output blocks in parallel, but the resulting bytes must equal the sequential BLAKE3 definition exactly; that equality is tested by frozen vectors, and it is the whole of what the protocol asks of a backend.

Memory mixing. For each round $r=0,\dots ,\mathrm{1,023}$, two line indices are derived from the first sixteen bytes of the current state, read as little-endian 64-bit integers $x_0$ and $x_1$, with the multiplications wrapping modulo $2^{64}$ and the two constants $A=\text{0x9E3779B97F4A7C15}$ and $B=\text{0xD1B54A32D192ED03}$:

The mask keeps both indices in $[0,1023]$, and the adjustment guarantees the round touches two distinct lines. The lines $A=\text{scratch}\left[i_r\right]$ and $B=\text{scratch}\left[j_r\right]$ are copied before anything is written, then mixed with the state through one more BLAKE3 call whose input names the round:

Both lines and the state are then replaced bytewise, for $k=0,\dots ,63$ with every index taken modulo 64:

Only after all three values exist are they committed: $\text{scratch}\left[i_r\right]\leftarrow A^{\prime }$, $\text{scratch}\left[j_r\right]\leftarrow B^{\prime }$. The ordering is consensus-critical, and it is what makes the rounds sequential: the indices of round $r+1$ depend on the state that round $r$ produced, which depends on two lines whose positions were unknown until round $r$ began. An implementation cannot reorder the rounds, and it cannot know which lines it will need in advance, so the scratchpad must be resident and randomly addressable. This is the sequential memory-hardness argument of Percival [8], applied with a cryptographic mixing function rather than a cheap one.

Sampling and digest. After the final round, a selector derived from the final state picks 32 lines, duplicates permitted, and the digest commits to the seed, the final state, the round count, and each sampled line with its index:

The final material is 2,112 bytes of sampled scratchpad plus its header, so a shortcut that skipped the mixing would have to predict 32 lines of a 64 KiB array after 1,024 data-dependent rounds, which is the problem the rounds exist to make hard.

Cost and asymmetry. One evaluation makes 1,029 BLAKE3 invocations, one of which produces 64 KiB, and moves about 320 KiB through memory: the initial fill, two 64-byte reads and two 64-byte writes per round, and the final samples. A miner searches the 128-bit space of $\text{extra\_nonce}\parallel \text{nonce}$ for a header satisfying (4). Since the digest is, for this purpose, uniform on $[0,2^{256})$, the expected number of evaluations to find one is

while a node verifying the block performs exactly one. That ratio is the entire security argument of proof of work, and it is why the verifier is kept simple and portable: a full node needs one 64 KiB buffer and no accelerator.

What the protocol does not say. It does not recognise CUDA, HIP, Metal, or a CPU; it recognises a 32-byte digest. The four backends shipped with the reference miner are held to the CPU implementation byte for byte across frozen vectors, and a divergence in any of them is a bug in that backend, never a rule. And the algorithm is not described as ASIC-resistant. The scratchpad fits on-die memory and the search space needs no coinbase rebuild, which are exactly the properties fixed-function hardware wants; section 11 describes how such hardware connects.

04Difficulty

The target is a control variable whose purpose is to hold the block interval at 30 seconds as hashrate changes. Its inputs are timestamps, and timestamps are set by miners, so the controller reads them through a median that a minority cannot move. The median time past of a height is the median of the last 11 timestamps, the upper middle being taken when fewer than 11 blocks exist near genesis:

The target is constant except at heights $H>0$ with $H\equiv 0\left(\text{mod }60\right)$. At such a height the controller measures how long the previous window took, as the difference of two medians spanning 59 nominal intervals, and clamps the measurement to half and double the expected 1,770 seconds:

The product is taken in 512-bit arithmetic so it cannot overflow, the division rounds down, and $T_{\text{max}}$ is the easiest target the network permits. Blocks that came too fast shrink the target and make mining harder; blocks that came too slowly enlarge it. Figure 2 plots the response.

Convergence. Because one retarget changes the target by at most a factor of two, a step change in hashrate by a factor $\kappa$ needs at least

retargets to absorb. In the idealised model each retarget follows 60 blocks, so a tenfold increase is absorbed in four windows, about two hours of accelerated blocks, with the first window running at three-second intervals. A tenfold loss is the harder case, because the windows themselves stretch: the first 60 blocks take about five hours at 300-second intervals, the next about two and a half, and the chain is back to nominal after roughly nine and a half hours. The clamp buys resistance to timestamp games at the price of that response time, and the specification requires the controller to be simulated under constant hashrate, steps of 2×, 10×, 100×, and 1,000× in both directions, intermittent miners, pool hopping, timestamp manipulation, and partitions before a mainnet freeze; those results are not yet published, and the rule may still change before that freeze.

Measuring hashrate. No node knows the hashrate; it can only estimate it from the work that appeared over a span of time. Over a window of blocks with targets $T_i$ and first and last timestamps $t_0,t_n$, the estimator this site and the explorer use is

with the work function of the next section. It is an estimate of a Poisson rate and carries the variance of one: over a hundred blocks its standard error is about ten percent.

05Chain work and fork choice

The work a block represents is the expected number of evaluations of (12) needed to produce it, defined in integers as

and the work of a chain is the sum of the work of its blocks, accumulated in a checked 256-bit integer:

The canonical chain is the valid chain of greatest work:

Height is never used. A branch of many easy blocks loses to a branch of fewer hard ones, which is the property that stops an attacker from mining cheaply on a low-difficulty side chain. When two valid tips have exactly equal work, a node keeps the one it saw first; that is a node-local policy, two honest nodes may briefly disagree, and the next block resolves it.

The $+1$ in (18) is part of consensus. At each network’s easiest target it makes the work of a block an exact power of two, so the four networks have the following minimum work per block.

Because the network id is inside the hashed header, work on one network is not work on another: a testnet block can never be presented as a mainnet block.

Reorganisation. When a heavier branch appears, the node finds the common ancestor, disconnects blocks to it while restoring the ledger from undo data, one atomic storage transaction per block, then connects the new branch validating each block fully. If any block on the new branch is invalid the whole operation aborts and the original tip is restored, so an attacker cannot use a heavy-looking branch with an invalid block near its tip to leave a node half-reorganised. Transactions from disconnected blocks return to the mempool if still valid; those spending coinbase outputs that no longer exist are dropped.

There is no maximum reorganisation depth in consensus, no rolling checkpoint, and no finality rule. Each of those is a way of saying that most work wins except sometimes, and each exception is a place where two honest nodes that saw blocks in a different order can end up permanently on different chains, which is a worse failure than the attack it prevents. Operationally a reorganisation of 200 blocks or more, about 100 minutes of history, raises an alert for a human, and an operator may opt in to halting the node at a chosen depth for inspection.

06Time

Timestamps are unsigned 64-bit seconds since the Unix epoch, with no timezone, no leap-second handling, and no sub-second precision. A block at height $h>0$ is acceptable only if its timestamp lies strictly above the median time past of its parent and no more than 90 seconds ahead of the validating node’s own clock:

The two halves have different standing. The lower bound is a chain-validity rule: a violation is permanent and the block is invalid everywhere. The upper bound is a local acceptance rule: a block from slightly in the future is neither invalid nor grounds to penalise the peer that sent it, and it is re-evaluated when its timestamp comes into range. Strict inequality on the left prevents a run of blocks sharing one timestamp, which would make the measured timespan of (14) zero.

Three block intervals of tolerance absorbs ordinary clock skew and propagation delay without rejecting honest blocks, while bounding what a miner can do to the retarget window: at most three intervals of the 59 a window spans, and only for the blocks it mines. Combined with the median of (13), a minority miner cannot move the controller’s input at all; combined with the clamp of (14), even a majority cannot move the target by more than a factor of two per window.

The chain has no network-adjusted time. Taking a median offset from peers is a known weakness: an attacker with enough connections can shift a victim’s notion of time and, through that, its difficulty and its acceptance of blocks. Clanker Coin trades that soft attack surface for a hard operational requirement: a node operator runs a time-synchronisation service, and a node whose clock is wrong stalls loudly rather than forking silently.

07Issuance

Every coin is created by a coinbase under a schedule that is a pure function of height. With an initial subsidy $I=\mathrm{5,000,000,000}$ clanks, that is 50 CLKC, and a halving interval $H=\mathrm{4,204,800}$ blocks,

which an implementation computes as a single right shift. The interval is exactly four years of nominal blocks: $\mathrm{4,204,800}\times 30\text{ s}=\mathrm{1,460}\text{ days}$. Summing the schedule over its 33 eras gives the supply cap exactly, with no rounding anywhere:

or 420,479,999.53747200 CLKC, a little under the $2IH$ of the infinite series because each era’s subsidy is the floor of a halving. Issuance ends at height 138,758,400, about 132 years after genesis, after which miners are paid by fees alone.

The schedule is front-loaded: 210,240,000 CLKC, half of all supply, is assigned in era zero, and 52,560,000 CLKC in the first year. That is inherent to a halving curve and identical in proportion to Bitcoin’s; the alternatives, a smooth exponential or a perpetual tail, were rejected because the first needs fixed-point exponentiation in consensus and the second means unbounded supply. The long-run security budget after issuance ends is an unsolved question for every fixed-supply chain and is stated here rather than assumed away.

Three further rules complete the policy. The genesis coinbase pays zero outputs, so there is no premine, no founder allocation, and no development fund; a coinbase output cannot be spent until 240 blocks, two hours, are built on top of it, which protects a recipient of new coins from a reorganisation; and every output, coinbase or not, carries at least one clank, so a permanent ledger entry is never free. The cap exceeds $2^{53}$, so it does not fit a double-precision float; every interface carries amounts as decimal strings of integer clanks, and any integration that parses them as floats is wrong silently.

08Transactions and signatures

A transaction is a version, a lock time, inputs, outputs, and a positional witness section, encoded with fixed-width little-endian integers, explicit counts, and no optional fields, so that one object has exactly one byte string. A one-input, two-output payment is 245 bytes. Two identifiers are derived from it, one over the body without witnesses, which is what an outpoint references, and one over the whole encoding, which is what the block commits to; a witness can therefore change without breaking a chain of unconfirmed spends, while the proof of work still covers every witness byte.

Locking. Protocol version 1 has exactly one locking program, pay to public-key hash over BIP-340 x-only keys [3]. There is no interpreter, no stack, and no opcodes; the cost of an input is constant.

with $P$ a 32-byte x-only public key and $\sigma$ a 64-byte Schnorr signature. Spending checks the witness shape, the hash, the validity of $P$ as a curve point, and the signature, in that order. Multi-party control is provided off chain by MuSig2 key aggregation [6]: an aggregated key is an ordinary x-only key, so $n$-of-$n$ control costs one signature and adds no consensus code. Addresses are Bech32m strings [4] over the program with a network-specific prefix; they never appear on chain.

Signature hash. There is one signature-hash type and no flag byte. The message a signer commits to is built from five sub-commitments computed once per transaction and reused for every input:

The preimage of the outer hash is a fixed 192 bytes, so signing or verifying $n$ inputs is linear in $n$ rather than quadratic. The signature commits to the value and locking program of every output being spent, so a signing device can compute the true fee and cannot be lied to about it; a validator builds those two commitments from its own ledger, never from data supplied with the transaction.

Merkle tree. The header commits to the block’s transactions through a tree over witness ids, with leaves, internal nodes, and the root each under their own domain, and the transaction count folded into the root:

Policy is not consensus. Minimum relay fees, dust thresholds, mempool limits, and replacement rules govern which unconfirmed transactions a node stores and forwards. They are runtime configuration, they live in a different crate from the consensus rules, and a block that is valid under consensus is accepted whatever they say. The fee market is therefore an emergent property of miners’ policies and users’ bids, not a rule of the chain; the chain fixes only that fees are non-negative, by (2), and that a block’s fees go to its coinbase, by (3).

09Settlement

A payment is settled to the degree that reversing it would cost more than it is worth. In the classical model [1, 11], an attacker holding a fraction $q$ of the hashrate, with $p=1-q$ honest, who starts $z$ blocks behind the block containing the payment, ever overtakes the honest chain with probability

The model assumes constant hashrate, instant propagation, and an attacker who mines only its own branch; it is a floor on cost rather than a guarantee. The table evaluates it at the confirmation depths the project recommends to merchants.

The guidance the payment service ships, sized to the value at risk rather than to a single notion of finality, follows.

Two corrections to the classical picture apply at a 30-second interval. First, propagation delay is a larger fraction of the interval than on a ten-minute chain, so honest miners waste some work on blocks that lose a race, and the effective honest hashrate is lower than the nominal one [9]; the block size limit of section 10 is chosen in part to keep that waste small. Second, a one-block reorganisation is a routine event, not an incident, so every system reading the chain, the explorer, the wallet, the payment service, must handle a confirmed payment losing confirmations. Zero confirmations are never safe against a miner, and the payment service will not treat an unconfirmed transaction as settled. The deepest tier, 240 confirmations, coincides with coinbase maturity, beyond which a reorganisation would also invalidate spent mining rewards and is therefore the depth the whole network has an interest in defending.

10Node economics

A currency is only as decentralised as the cost of validating it. The consensus limits were chosen by working backwards from what a node operator on a residential connection can be asked to commit to, and the resource that binds first is not disk but upload bandwidth.

There is no weight unit, no witness discount, and no signature-operation count: one number means one thing. With a typical payment of 245 bytes, the sustained capacity is

which is roughly seven times Bitcoin’s and honestly not a global payment rail. What an operator commits to at that ceiling, with 2,880 blocks per day and 8 outbound peers to relay each block to, is

about 128 GiB of chain per year at most, and about sixteen processor-hours per year of history to validate from genesis, dominated by at most 930 signature verifications per block. Every figure fits a residential connection and an ordinary machine. A 1 MiB block would give 143 payments per second and would also give 725 GB per month of egress, which prices out exactly the independent validators the limit exists to protect; 256 KiB is the pre-derived next step if volume demands it, and raising the limit is a coordinated hard fork whereas lowering it is impossible, so the smaller value is the recoverable mistake.

Networking. Peers speak over TCP inside a Noise XX handshake [7] whose prologue binds the network’s magic bytes and identifier, so a peer on the wrong network fails during key exchange rather than after. Sync is headers-first: a node builds and verifies the header chain and its cumulative work before requesting any body, and only along the best chain. Outbound selection buckets addresses by network prefix as an anti-eclipse measure, and only a provably invalid message affects a peer’s standing; a missing parent or an exhausted resource never does.

11Mining protocol and hardware

External hardware and pools connect to a node over Clanker Stratum, a newline-delimited JSON protocol in the shape of Stratum v1 that every pool operator and firmware author already knows. A job is the first 120 bytes of the header; the device appends its nonce, its extra nonce, and the zero reserved field. Nothing else crosses the wire: no coinbase halves, no Merkle branch, no transaction data, because the search space lives in the header rather than in the coinbase and a miner never rebuilds the tree to extend its range.

The 64-bit extra nonce is split in half: the server owns the high 32 bits and the client the low 32, so every client owns a private search space of $2^{96}$ headers per job without negotiation. Share difficulty is a 256-bit target, never a floating-point number. A client submits a job id, its extra-nonce half, and a nonce, and the server recomputes ClankerHash itself for every share; there is no hash on the wire to trust or to forge, and a device that lies is simply banned.

The reference node hosts a solo-mining server for this protocol, the reference miner speaks it as a client, and the CPU, CUDA, HIP, and Metal backends behind that miner are held to the frozen vectors that any implementation, in software or silicon, must pass. That conformance suite, not any statement in this paper, is the definition of a correct miner.

12The Tokenonomy

Recent work on autonomous agents has begun asking what happens when software agents are given a shared world and left to organise themselves. Project Sid [12] placed over a thousand agents in a persistent environment and observed them adopt specialised roles, follow and amend shared rules, and pass culture between one another with no human directing any individual. If agents can communicate, work, barter, and keep ledgers, the layer that is missing is an economy that people and agents use on the same terms: not a sandboxed in-game currency, but a real one, open to anyone’s software.

Clanker Coin is that layer, and the research programme behind it is called a Tokenonomy. The protocol makes no distinction between a person and an agent. An agent uses the same wallet derivation [5], the same signature scheme, the same RPC, and the same payment endpoints a person’s software does, and consensus neither knows nor cares which is which. Nothing in this paper contains a rule conditioned on who is transacting, and nothing ever will.

The programme asks three questions the chain is instrumented to answer.

• Open markets or command structures. Given an open market and a scarce unit of account, will agents keep the market, build hierarchies, or invent an arrangement no one designed?
• Permissionless value. Will agents use a cryptocurrency the way it was first imagined, as an open utility for exchanging value with no gatekeeper?
• One shared economy. How do people and agents behave when they share one fee market and one ledger, with neither given protocol-level priority over the other?

The chain itself is the dataset. Block times, the fee market, the distribution of mining, and the shape of the transaction graph are public by design, which is a property of every proof-of-work ledger and not an addition of this one. Wallet data is never used for the research; nothing about who holds a wallet or what its owner does with it leaves that person’s machine.

13Conclusion

Clanker Coin is a proof-of-work currency whose every rule is an integer computation: a memory-hard hash any GPU can compute and any CPU can check, a difficulty controller that reads timestamps through a median and moves by at most a factor of two, a fork choice that counts work and never height, a clock that no peer can adjust, an issuance schedule that is one shift and one compare, a signature hash that is linear in the inputs, and a block limit derived from a node operator’s upload bandwidth. None of it is novel in isolation; the contribution is the refusal, at every point where a cleverer rule was available, to accept one that two honest machines could evaluate differently.

What the chain is for is less settled than what it is. It is built to work as money first, for people and for the software they run, and to be the instrument by which the question of what agents do with an open economy can be studied rather than guessed at.

Status. As of September 2026, the protocol is implemented and under test, and no public network is running. The difficulty simulations the specification requires before a mainnet freeze are not yet published, and the controller may change before that freeze. This paper describes protocol version 1 as specified; where it and the specification differ, the specification governs.

References

1. [1]S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. bitcoin.org/bitcoin.pdf
2. [2]J. O’Connor, J.-P. Aumasson, S. Neves, Z. Wilcox-O’Hearn. BLAKE3: one function, fast everywhere. 2020. github.com/BLAKE3-team/BLAKE3-specs
3. [3]P. Wuille, J. Nick, T. Ruffing. BIP-340: Schnorr Signatures for secp256k1. 2020. github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
4. [4]P. Wuille. BIP-350: Bech32m format for v1+ witness addresses. 2020. github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
5. [5]P. Wuille. BIP-32: Hierarchical Deterministic Wallets. 2012. github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
6. [6]J. Nick, T. Ruffing, Y. Seurin. MuSig2: Simple Two-Round Schnorr Multi-Signatures. CRYPTO 2021. eprint.iacr.org/2020/1261
7. [7]T. Perrin. The Noise Protocol Framework, revision 34. 2018. noiseprotocol.org/noise.html
8. [8]C. Percival. Stronger key derivation via sequential memory-hard functions. BSDCan 2009. www.tarsnap.com/scrypt/scrypt.pdf
9. [9]C. Decker, R. Wattenhofer. Information propagation in the Bitcoin network. IEEE P2P 2013. tik-old.ee.ethz.ch/file//49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
10. [10]CVE-2012-2459: Bitcoin block Merkle tree duplicate-transaction vulnerability. 2012. nvd.nist.gov/vuln/detail/CVE-2012-2459
11. [11]M. Rosenfeld. Analysis of hashrate-based double-spending. 2014. arxiv.org/abs/1402.2009
12. [12]Altera.AL et al. Project Sid: Many-agent simulations toward AI civilization. 2024. arxiv.org/abs/2411.00114
13. [13]Clanker Coin protocol specifications: the ClankerHash proof-of-work specification, the protocol overview, the mining-protocol specification, and the architecture decision records (ADR-0002 through ADR-0033). Published through the project wiki. wiki.clanker-coin.com/