Hand-signed hash-based signatures for a proof-of-work ledger

1. Introduction

Bitcoin^[16] and most systems that followed it authorise transfers with ECDSA or Schnorr signatures over the secp256k1 curve^[27],[25]. Their security rests on the hardness of the elliptic-curve discrete logarithm problem, which a sufficiently large quantum computer running Shor's algorithm would solve in polynomial time^[11]. Aggarwal et al. estimate when such an attack could outpace block confirmation, and discuss migration to other signatures^[14]. Hash-based signatures are the most conservative alternative. Their security depends only on properties of a hash function, and they have now been standardised in both stateful and stateless forms^[6]–[9].

A second, more practical problem is device trust. Whatever the signature scheme, the signing key normally lives on a phone, a computer or a dedicated hardware device, and that device must be trusted at setup and at every signature. This paper explores a different point in the design space. Can the key live only on paper, and can a person produce a valid signature from it by copying rather than computing?

Lamport's original one-time signature^[1] suggests that this is possible. Signing a message reveals one pre-committed secret per message symbol, and needs no computation by the signer. The difficulty lies elsewhere. A Lamport key can sign only one message, the message must be short enough to copy, and the signer must never reuse a key. We address these problems as follows.

1. A message small enough to copy. A transfer is 18 decimal digits: a sequential, ledger-assigned account number with a Damm check digit^[18], a four-digit mantissa, an exponent and a fee tier (Section 4.2). Signing reveals 18 cells.
2. Key state held by the ledger. Each account carries an on-chain counter of consumed one-time keys. Signers keep no state other than the paper (Section 4.6).
3. Self-authenticating pieces. Each revealed cell can be verified on its own, so a signature can be submitted column by column from different computers (Section 4.7).
4. An analysis and an implementation. We analyse the scheme against forgery, replay, double reveal and human error (Section 5), and release a reference node and a public research network (Section 6).

We make no claim that this design is suitable for general use. It is a research artefact for examining the costs and limits of human-computable, hash-only authorisation.

2. Background and related work

2.1 One-time and few-time signatures

Lamport's scheme^[1] commits to two random secrets per message bit and signs by revealing one of each pair. Winternitz's variant, described by Merkle^[2], trades signature size for hash computations by iterating a hash chain per message digit. Merkle trees^[2],[3] bind many one-time public keys to a single root. Our scheme is a Lamport scheme over a base-10 alphabet. Each column has ten secrets, one per digit, and signing reveals exactly one. We deliberately avoid Winternitz chains, because evaluating a hash is not something a person can do by hand.

2.2 Stateful and stateless hash-based signatures

XMSS^[7] and LMS^[8] are stateful many-time schemes built from one-time signatures and Merkle trees. NIST SP 800-208^[9] approves them but stresses that reuse of a one-time key can be catastrophic, and that state management is the main operational risk. SPHINCS^[4] and SPHINCS^+[5] remove the state at the cost of larger signatures. SPHINCS⁺ was standardised as SLH-DSA in FIPS 205^[6]. We borrow only SLH-DSA's tweakable hash construction, whose address tweaks and public salt mitigate multi-target attacks^[10]. The ledger itself serves as the state that SP 800-208 asks implementers to protect.

2.3 Quantum attacks

Shor's algorithm^[11] breaks the discrete logarithm and factoring problems. Grover's algorithm^[12] speeds up generic preimage search quadratically, and Zalka showed that this speed-up is optimal^[13]. For a k-bit preimage, a quantum attacker therefore needs about 2^k/2 sequential evaluations. Bernstein and Lange survey the resulting landscape^[15]. SLH-DSA parameter sets with 128-bit hash outputs are assigned to NIST security category 1^[6],[24], which is defined by the cost of AES-128 key search.

2.4 Paper keys and check digits

BIP-39^[17] encodes 128 to 256 bits as words from a 2,048-word list with a checksum, and is widely used for paper seed backups. In existing systems the paper is only a backup, and signing still happens on a device. Our scheme reuses the word list as the printed form of every secret. For account numbers we use the Damm algorithm^[18], which detects every single-digit error and every adjacent transposition, like Verhoeff's earlier code^[19], but uses a single table lookup per digit.

2.5 Ledger structure

We keep Bitcoin's SHA-256d proof of work and its issuance per hour^[16], but use an account model in the style of Ethereum^[21]. A cheque names its recipient by account number and consumes a per-account counter, and both are account state. The slow-start reward follows Zcash^[23]. Merged mining^[22] is an open option discussed in Section 7.

3. System model and goals

Parties. A holder owns a printed book. A printing computer derives and prints the book once, offline. A broadcasting computer is any untrusted machine that receives the copied cells and relays them. Nodes validate transactions, and miners produce blocks.

Adversary. The adversary sees every message on the network and every byte on the ledger, may fully control the broadcasting computer, and may have a large quantum computer. The adversary cannot read the holder's paper. In the standard one-seed book the printing computer is trusted during the single printing session. The split-key variant (Section 4.8) removes that trust, but the website does not yet offer it.

Goals.

1. G1, hash-only verification: everything a node checks reduces to SHA-256 and equality tests.
2. G2, hand signing: producing a signature requires reading and copying, with no arithmetic. Scanning printed QR codes is an optional shortcut, not a requirement.
3. G3, paper recovery: the whole book can be regenerated from a 24-word seed.
4. G4, no off-chain state: no signer or device keeps a counter.
5. G5, untrusted broadcast: the broadcasting computer can withhold a cheque but cannot alter it.

Non-goals. High throughput, privacy comparable to fresh-address UTXO systems, and convenience for frequent transfers are explicitly out of scope.

4. Design

4.1 Hash primitive

All book commitments use tweakable SHA-256^[20] in the SLH-DSA-SHA2 style^[6], truncated to n = 16 bytes by default:

The 16-byte salt is public and chosen per book. The address binds every hash to one position in one book, so an attacker cannot attack many targets at once^[10]. An optional n = 32 mode doubles every size. Key and cell derivation (Section 4.3) use plain SHA-256 with distinct labels. Proof of work, transaction identifiers and the transaction tree use SHA-256d, as in Bitcoin. No encryption is used anywhere in consensus.

4.2 The cheque message

A cheque says exactly one thing, in 18 decimal digits.

Table 1. The cheque message.

Two encodings are reserved. Mantissa 0000 with exponent 0 is a zero-amount cheque, used as an honesty check. Mantissa 0000 with exponent 9 sweeps the whole balance minus the fee. Any other exponent with mantissa 0000 is invalid. Fee tier 0 is valid only on a zero-amount cheque. Account numbers are assigned by the ledger in order of first appearance. A number is reassigned only after a never-funded account is deleted, and then only after a quarantine of 525,600 blocks (about a year). A number may be named as a recipient only once the block that assigned it is 100 blocks deep. This prevents a reorganisation from redirecting a transfer.

4.3 Books and key derivation

A book is derived from one 256-bit seed, written as 24 BIP-39 words^[17]:

Each cell is 128 bits and is printed twice: as a 12-word BIP-39 mnemonic, with the standard 4-bit checksum, and as a QR code of its 32 hexadecimal digits labelled with its position. A standard book holds 12 cheques. Cheque 0 is the honesty check (Section 4.4); it is sent automatically with the registration and is never printed. Cheques 1 to 10 are for transfers, and cheque 11 is kept for a final sweep of the whole balance to a new book. Books registered before this layout was adopted hold 11 cheques, with cheque 10 as the sweep, and remain valid. The printing computer prints the book as two parts in separate print runs, ideally on two printers. Part A holds the 12 recipient columns, and part B holds the 6 amount, exponent and fee columns. Someone who finds only one part cannot write a cheque, because every cheque needs cells from both.

4.4 Commitments and registration

For each cell, every share (one in a standard book, m in a split book) is hashed, and the share hashes are combined into one commitment:

A RegisterBook transaction carries the share hashes of every cheque in the book. It needs no signature, because every node recomputes the commitments, leaves and root and checks that they match the account identifier. A third party can only register the holder's true hashes. To limit spam, registration carries a small proof of work (a target of about 2²⁸ SHA-256d evaluations, with a hard cap of 200 such registrations per block); proof of work is the only way to register. The website mines it in the browser on all processor cores, typically in a minute or two, and sends cheque 0 with it: a zero-amount cheque to the reserved number 0 whose 18 digits are all zero. An account registered by proof of work that never receives a transfer or a matured reward is deleted after 43,200 blocks (30 days). Registered cheques expire after 2,100,000 blocks (about four years) unless renewed for a small fee, which bounds the state left by abandoned books.

4.5 Signing and verification

To sign, the holder writes the recipient and amount, and for each of the 18 columns copies the cell in the row of that column's digit, either by typing its 12 words or by scanning its QR code. The result is 18 cells, or 216 words. The broadcasting computer hashes each cell under each candidate address. A cell matches exactly one stored commitment, so the computer can decode the message and show it to the holder for confirmation. Because it knows every commitment, it can also reject a mistyped cell the moment it is entered. A piece names its column but not its row, so each node tries the rows of that column in turn until one satisfies

When all 18 columns of cheque N are revealed, the node verifies the Damm check digit over the 12 recipient digits, confirms that the recipient exists and is mature, checks that the balance covers the amount and fee, applies the transfer, and deletes cheque N's commitments.

4.6 One-time key state on the ledger

Each account stores a counter, nonce, holding the highest cheque number consumed. A piece for cheque N is accepted only if N > nonce, or if N is the cheque currently open. The first accepted piece sets nonce := N. Each column of a cheque can be revealed only once, so every digit is fixed as soon as its piece is accepted. Starting a higher-numbered cheque discards any unfinished one. A used cheque can therefore never be replayed, and a lower-numbered cheque that was written but never broadcast is voided once any higher number is used. Pieces of an unfinished cheque expire 10,000 blocks (about a week) after the most recent accepted piece, and the number stays consumed. The signer keeps no state. The paper is the state, and the ledger records which numbers are used.

4.7 Piecewise submission

Because each cell's commitment identifies its account, cheque, column and row, a cheque can be submitted as up to 18 independent ChequePiece transactions. These may come from different computers, places and times. Wallets submit the recipient columns first, so the recipient is fixed on the ledger before the amount is public. Each piece carries all m shares of its cell. A cheque has at most 18 accepted pieces, and only the paper holder can produce them. Invalid pieces cost nodes a bounded hashing effort to reject.

4.8 Split-key books

In the optional split-key book, each cell is the concatenation of m shares, each derived on a separate computer from its own seed. Each computer publishes only its share hashes, and any computer can combine them into the commitments of Section 4.4. Compromising one printing computer then reveals no complete cell. A dishonest computer could print one set of shares but publish hashes of another, leaving the book unusable. The zero-amount cheque 0 detects this before the account receives any transfer, but only for cheque 0's own cells, all of which are row 0. It cannot detect a computer that corrupts only cheques 1 to 11. A full check means comparing every printed share against its published hash on an independent computer. Consensus accepts any m from 1 to 7. The standard book uses m = 1.

4.9 Consensus

Blocks use SHA-256d proof of work with a 60-second target and a 112-byte header that adds a 32-byte state root to Bitcoin's fields. Difficulty adjusts every block using a linearly weighted moving average over 60 blocks^[26], limited to a factor of 3 per block, because a small chain cannot survive Bitcoin's 2,016-block window. The research network and local test chains add stall relief: once the chain has been silent for two targets beyond the latest of the last 11 timestamps plus the 12-minute future-time allowance, the target doubles for every further two targets of silence, so a chain abandoned at a high difficulty can be restarted by whoever remains. Measuring from the latest recent timestamp, not the previous one, defeats the Bitcoin testnet exploit of alternating low and far-future timestamps; a future production network, which must resist difficulty manipulation, would have no such rule. With blocks ten times as frequent as Bitcoin's, the reward is a tenth of Bitcoin's: 5 coins, halving every 2,100,000 blocks (about four years), so coins are created at Bitcoin's rate per hour and the supply stays under 21 million. On a production network the reward ramps linearly from zero over the first 200,000 blocks^[23]. Rewards mature after 100 blocks. Blocks hold at most 1 MB, and a block's timestamp may be at most 12 minutes ahead of the node's clock. Block 0 has no premine. Its reward transaction names the reserved account 0, which no one controls, and under the slow start it carries no reward. While the network is new, all of these parameters may change and the chain may be reset.

5. Security analysis

The analysis below is informal. We have not produced a machine-checked proof, and the design has not been externally audited.

5.1 Unforgeability

To produce a valid piece for a digit the holder did not reveal, an attacker must find a share whose hash chain matches an unrevealed commitment. That is a preimage of the truncated, tweaked hash. With n = 16 bytes this costs about 2¹²⁸ classical evaluations, or about 2⁶⁴ sequential quantum evaluations using Grover's algorithm^[12],[13]. The salt and address tweak prevent an attacker from amortising this search over many commitments^[10]. Because the message is signed directly rather than hashed, unforgeability by outsiders rests on preimage resistance. Collision resistance of the 128-bit tree hashes, about 2⁶⁴, matters only to parties who build the commitments, such as a printing computer. Holders who want a larger margin may choose n = 32 bytes.

5.2 Replay and reuse

The nonce rule of Section 4.6 makes each cheque number usable once. Key reuse, the central risk of stateful schemes^[9], can happen only if two different messages are written on cheques with the same number. That requires writing a second message on the same cheque, for example after a broadcasting computer saw a first version (Section 5.4), or using both a book and its reprint. The operating rule is to consume a number above anything the original could still hold before using a reprint.

5.3 Double reveal

Suppose two different messages for the same cheque number both become public before either confirms. An attacker can then combine revealed cells column by column. The resulting recipient must still pass the Damm check and name an existing, mature account. With up to 2¹² recipient combinations, of which about one in ten pass the Damm check, the attacker can redirect only to an account that happens to appear among them. In the amount columns the attacker can pick, per column, the larger digits or the higher fee tier, and a mining attacker collects that fee. Once the recipient columns are fixed on the ledger, the remaining exposure is a different amount to the recipient already chosen. We consider this a bounded but real risk of misuse, and wallets should refuse to sign a second message for any number already seen on the ledger.

5.4 Untrusted broadcasting computer

The broadcasting computer learns the 18 revealed cells, which authorise only the message that was written. It can decline to broadcast, or claim to have broadcast when it did not. In that case it holds a cheque that remains valid until voided. The holder voids it by confirming a zero-amount cheque with a higher number before writing the transfer again. The computer cannot change the recipient or the amount without a preimage.

5.5 Transcription errors

Human copying is the dominant failure mode. Four layers catch errors. A misspelt word is not in the BIP-39 list. A wrong but valid word fails the 4-bit checksum with probability 15/16. A cell with a correct checksum but wrong content fails to match any stored commitment. A wrong recipient digit fails the Damm check, which detects every single-digit substitution and adjacent transposition^[18]. The amount digits have no check digit, so the confirmation screen of Section 4.5 is the only defence against an amount copied from the wrong row. An optional nineteenth check column is listed as an open question in Section 7.

5.6 Dishonest key generation

In a split-key book, a dishonest printing computer cannot steal, because it lacks the other shares. It could corrupt a few cells so that particular digits become unsignable. The honesty check proves only the 18 revealed cells of cheque 0, out of 2,160 in a twelve-cheque book, so such sabotage can go undetected until a cheque fails. The effect is denial of specific amounts, not theft. In a standard one-seed book, the printing computer sees every cell, so offline printing is the main defence.

5.7 Physical and ledger-level threats

Paper carries the authority to sign. Anyone holding both parts of an unused cheque can write it. Splitting parts A and B across locations raises the bar, but coercion, theft and cameras over the signing desk are outside the cryptographic model. At the ledger level, a young proof-of-work chain is exposed to majority-hashrate attacks and deep reorganisations: SHA-256d hash power can be rented, so a small chain can be rewritten cheaply. For a research network this is acceptable because its coins carry no promise of value.

6. Implementation and costs

The reference node is written in Rust using only the standard library, with no external crates. It has about 2,500 lines across modules for SHA-256 (an independent FIPS 180-4 implementation^[20]), the tweakable hash, the Damm check, message encoding, book commitments, transactions, state with a Merkle state root and account proofs, blocks and difficulty, block storage with most-work chain selection, peer-to-peer relay and a plain-text HTTP RPC. A dry-run endpoint lets a wallet check all 18 pieces of a cheque against current state before broadcasting. As a node policy, not a consensus rule, a new account number is published only once it is 100 blocks deep; until then the holder finds the account through a lookup code, the first 12 hexadecimal digits of its account identifier, printed on the cheque sheets. The website's wallet compiles the same Rust code to WebAssembly, with a small QR encoder and camera reader, about 600 further lines; it derives the book, mines the registration and builds cheque pieces in the browser.

The tests exercise the life of a chain end to end. They cover mining from block 0, registration by proof of work, the honesty check, reward maturity, a transfer between books, piecewise submission split across blocks, rejection of replays, wrong shares and wrong check digits, expiry of an unfinished cheque, and a sweep. Further tests cover reorganisation, persistence, snapshots, state proofs, peer synchronisation and malformed input. The hash of block 0 is cross-checked against an independent Python implementation.

Table 2. Costs for a standard book (m = 1, n = 16 bytes).

The throughput figure is an upper bound that ignores registrations and other transactions. Whatever the exact figure, the system is several orders of magnitude slower than conventional transfer networks, which is consistent with its non-goals.

7. Limitations and open questions

• Usability is unmeasured. We have not run a user study. Copying 216 words with four-letter autocomplete is roughly 900 keystrokes; scanning the 18 QR codes is quicker but needs a camera. Error rates and completion times are unknown.
• Amount integrity. An optional nineteenth column carrying a Damm digit over all 18 digits would make any single copying error invalidate the cheque, at the cost of one more cell.
• Privacy. Sequential account numbers in an account model link every transfer of a book. Privacy is worse than in systems that use fresh addresses. The node a client talks to also sees the client's IP address and every account, lookup code and cheque it asks about.
• Finite books. A printed book allows ten transfers and a final sweep, after which the holder prints and registers a new one. Registered cheques also expire after 2,100,000 blocks unless renewed.
• Registration difficulty. The registration target adjusts every 20,160 blocks (two weeks) toward a quarter of the per-block cap, by at most a factor of four per window. Whether this bounds state growth under sustained registration spam, and whether the fixed per-block cap of 200 is itself too generous for printed books (each costs every node about 32 KB of state), has not been analysed.
• Fee adjustment. The fee unit is a constant. A rule that tracks recent fees is not yet specified, and miners currently fill blocks oldest first rather than by fee.
• Engineering simplifications. A reorganisation rebuilds state from the latest snapshot, taken every 1,000 blocks; a deeper reorganisation replays from block 0. Peer connections are not yet encrypted, and the mempool is not persisted across restarts.
• Majority attacks and merged mining. Hash power for SHA-256d can be rented by the hour, so an attacker could rewrite a small chain's recent history at little cost. Merged mining with Bitcoin^[22] would greatly raise the cost of majority attacks on a small chain, but it is not implemented.
• Recovery tools. A book can be regenerated from its seed with the reference wallet, but the website's restore and reprint steps are not yet complete.
• Formal assurance. No formal proof or external audit has been done. The design notes and code are published so that others can review them.

8. Research ethics and network statement

Bitcheque is operated by ALUSOFT PTY LTD as a non-commercial, experimental research network. Coins are issued only by mining; the operator does not sell them and makes no promise of value, service or stability. Anyone who trades them does so at their own risk, outside the operator's control. They are not sold by us and must not be sold or traded. There is no token sale. The network may be reset, changed or shut down at any time. The website collects no personal data and needs no account. It stores only preferences, such as the language, the chosen node and the project acknowledgement, in the visitor's own browser. The node a browser talks to can see its IP address. Participants are asked never to enter the seed or password of any other wallet. Use of the network is governed by the terms of use.

9. Conclusion

A ledger can be authorised by signatures that a person copies by hand and that nodes verify with SHA-256 alone. Three choices make this work: a decimal message small enough to copy, a Lamport scheme over a base-10 alphabet with SLH-DSA-style tweaked hashing, and one-time key state held by the ledger rather than by the signer. The cost is substantial. Signatures are large to copy, books are finite, throughput is low, privacy is weak, and human error replaces device compromise as the main operational risk. Measuring that trade-off on a live network, especially the human error rate, is the purpose of this project.

Availability. The design notes, reference node and website are published under the MIT licence.

References

1. L. Lamport, "Constructing digital signatures from a one way function," SRI International Computer Science Laboratory, Tech. Rep. CSL-98, Oct. 1979.
2. R. C. Merkle, "A certified digital signature," in Advances in Cryptology – CRYPTO '89, LNCS vol. 435, Springer, 1990, pp. 218–238.
3. R. C. Merkle, "Secrecy, authentication, and public key systems," Ph.D. dissertation, Stanford University, 1979.
4. D. J. Bernstein, D. Hopwood, A. Hülsing, T. Lange, R. Niederhagen, L. Papachristodoulou, M. Schneider, P. Schwabe and Z. Wilcox-O'Hearn, "SPHINCS: practical stateless hash-based signatures," in Advances in Cryptology – EUROCRYPT 2015, LNCS vol. 9056, Springer, 2015, pp. 368–397.
5. D. J. Bernstein, A. Hülsing, S. Kölbl, R. Niederhagen, J. Rijneveld and P. Schwabe, "The SPHINCS⁺ signature framework," in Proc. ACM CCS 2019, 2019, pp. 2129–2146.
6. National Institute of Standards and Technology, "Stateless Hash-Based Digital Signature Standard," FIPS 205, Aug. 2024. doi:10.6028/NIST.FIPS.205.
7. A. Hülsing, D. Butin, S. Gazdag, J. Rijneveld and A. Mohaisen, "XMSS: eXtended Merkle Signature Scheme," RFC 8391, IRTF, May 2018.
8. D. McGrew, M. Curcio and S. Fluhrer, "Leighton-Micali Hash-Based Signatures," RFC 8554, IRTF, Apr. 2019.
9. D. A. Cooper, D. C. Apon, Q. H. Dang, M. S. Davidson, M. J. Dworkin and C. A. Miller, "Recommendation for Stateful Hash-Based Signature Schemes," NIST SP 800-208, Oct. 2020. doi:10.6028/NIST.SP.800-208.
10. A. Hülsing, J. Rijneveld and F. Song, "Mitigating multi-target attacks in hash-based signatures," in Public-Key Cryptography – PKC 2016, LNCS vol. 9614, Springer, 2016, pp. 387–416.
11. P. W. Shor, "Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer," SIAM Journal on Computing, vol. 26, no. 5, pp. 1484–1509, 1997.
12. L. K. Grover, "A fast quantum mechanical algorithm for database search," in Proc. 28th ACM Symposium on Theory of Computing (STOC), 1996, pp. 212–219.
13. C. Zalka, "Grover's quantum searching algorithm is optimal," Physical Review A, vol. 60, no. 4, pp. 2746–2751, 1999.
14. D. Aggarwal, G. K. Brennen, T. Lee, M. Santha and M. Tomamichel, "Quantum attacks on Bitcoin, and how to protect against them," Ledger, vol. 3, pp. 68–90, 2018. doi:10.5195/ledger.2018.127.
15. D. J. Bernstein and T. Lange, "Post-quantum cryptography," Nature, vol. 549, pp. 188–194, 2017.
16. S. Nakamoto, "Bitcoin: A peer-to-peer electronic cash system," 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf
17. M. Palatinus, P. Rusnak, A. Voisine and S. Bowe, "Mnemonic code for generating deterministic keys," Bitcoin Improvement Proposal 39, 2013.
18. H. M. Damm, "Total anti-symmetrische Quasigruppen," Ph.D. dissertation, Philipps-Universität Marburg, 2004.
19. J. Verhoeff, Error Detecting Decimal Codes, Mathematical Centre Tracts 29, Mathematisch Centrum, Amsterdam, 1969.
20. National Institute of Standards and Technology, "Secure Hash Standard (SHS)," FIPS 180-4, Aug. 2015. doi:10.6028/NIST.FIPS.180-4.
21. G. Wood, "Ethereum: A secure decentralised generalised transaction ledger," Ethereum Yellow Paper, 2014.
22. A. Judmayer, A. Zamyatin, N. Stifter, A. G. Voyiatzis and E. Weippl, "Merged mining: Curse or cure?," in Data Privacy Management, Cryptocurrencies and Blockchain Technology (DPM/CBT 2017), LNCS vol. 10436, Springer, 2017, pp. 316–333.
23. D. Hopwood, S. Bowe, T. Hornby and N. Wilcox, "Zcash protocol specification," Electric Coin Company, 2016 onwards.
24. National Institute of Standards and Technology, "Submission requirements and evaluation criteria for the post-quantum cryptography standardization process," Dec. 2016.
25. P. Wuille, J. Nick and T. Ruffing, "Schnorr signatures for secp256k1," Bitcoin Improvement Proposal 340, 2020.
26. zawy12, "LWMA difficulty algorithm," difficulty-algorithms repository, GitHub, issue 3, 2017–2018.
27. Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters," Standards for Efficient Cryptography, version 2.0, Jan. 2010.