Working paper v0.1 · 2026-08-22 · Canonical: docs/whitepaper.md

BITFUC: An Independently Identified Instance of Nakamoto Electronic Cash

Not a prospectus. Not an offering. Not a claim that FUC is money, legal tender, or a store of value. Software licensed under MIT — not affiliated with the Massachusetts Institute of Technology.

Field	Value
Protocol	BITFUC
Unit	FUC
Implementation	Bitcoin Core v31.1 derivative (`bitfucd`)
Status	Node, descriptor wallet, local wallet UI, mining, ASERT, agent JSON API. Independent of Bitcoin.

Abstract. A digital bearer instrument that can be transferred without a trusted bookkeeper requires three things ordinary databases do not provide: a rule for who may create new units, a rule that forbids spending the same unit twice, and a rule for deciding which history is canonical when two histories conflict. Nakamoto (2008) gave a construction that meets those requirements by combining a UTXO transaction algebra with a most-work chain of proof-of-work headers. BITFUC is not a new consensus theorem. It is an independently identified instance of that construction: the same validation kernel, a disjoint network identity, a genesis coinbase that does not enter the UTXO set, and a written policy of zero developer allocation. This paper states the model, records the parameters that exist, and marks the parameters that do not. It does not argue that BITFUC will displace existing money, that FUC has a price, or that this website is a custodian.

Keywords: electronic cash; UTXO; Nakamoto consensus; proof of work; monetary parameterization; network identity; premine; Bitcoin Core.

1. Introduction
2. Related work
3. Preliminaries
4. The intermediated-money problem
5. Transactions as a conservative rewrite
6. The ledger as a most-work tree
7. Difficulty and the public-net objection
8. Scripts and names of coins
9. Monetary parameterization
10. BITFUC as a specified instance
11. Implementation
12. Security discussion
13. What this paper does not establish
14. Further work
15. Conclusion
Appendices and references

1. Introduction

Money, in the narrow operational sense used here, is a coordination device: a widely accepted object that extinguishes obligations and is itself accepted in further exchange (Jevons 1875; Menger 1892). Modern retail money is almost entirely intermediated. A bank or a card network keeps a ledger; the user’s “balance” is an IOU against that ledger; transfer is an instruction to the intermediary. That arrangement is efficient. It is also a trust assumption. The intermediary may freeze, reverse, inflate by policy, fail operationally, or be compelled.

Electronic cash is the attempt to recover the bearer property of notes without a note-issuer: the right to transfer is the knowledge of a secret, and the public record of which secrets still control which units is maintained by a protocol rather than a firm.

Chaum (1982) showed that a blind-signature mint can issue unlinkable electronic coins, but the mint remains a trusted issuer. Dai (1998) and Back (2002) sketched computational cost as a way to issue tokens without a mint. Haber and Stornetta (1991) showed how to time-stamp a document stream with hash pointers. Nakamoto (2008) composed these ideas into a system in which (i) units are unspent transaction outputs, (ii) authorization is a digital signature under a public verification key, and (iii) the canonical history is the chain of headers that represents the most accumulated proof of work.

BITFUC stands in that line. The engineering claim is narrower and, we think, more honest:

The validation rules are those of Bitcoin Core 31.1, not a reimplementation of secp256k1 or Script.
The network is not Bitcoin. Genesis, magic bytes, ports, address prefixes, and datadir are disjoint.
No developer output is inserted at genesis. The genesis coinbase is OP_RETURN and, as in Bitcoin, genesis outputs are not placed in the UTXO set.
Keys are held by whoever runs the node. This project does not operate a hosted wallet.

A paper that announced “a new money” while those four sentences were false would be a marketing document. This is not that paper.

1.1 What is claimed

We claim only what can be checked from source and from a local node:

There exists a C++ implementation, derived from Bitcoin Core tag v31.1, that validates BITFUC chains.
A local wallet UI and CLI can mine, transfer, and backup keys on a node the operator controls.
Address, magic, and port spaces are constructed so as not to collide with Bitcoin’s.
Public money: 1e9 FUC cap, two-minute blocks, ≈76.10 FUC subsidy for 13,140,000 heights, 2% fee burn, atom = bit.

1.2 What is not claimed

We do not claim that BITFUC is legal tender, that FUC has or will have exchange value, that the system is a substitute for bank deposits, that SHA-256d on a low-hashrate public net is secure against existing ASIC fleets, or that this project is affiliated with any university.

2. Related work

Blind-signature cash. Chaum (1982, 1988) and Chaum, Fiat, and Naor (1988) give anonymous electronic cash under a mint. The mint is the money. BITFUC has no mint.

Proof of work. Dwork and Naor (1992); Back (2002). Nakamoto uses SHA-256d on a block header as the puzzle.

Hash-linked time-stamping. Haber and Stornetta (1991); Bayer, Haber, and Stornetta (1993). The Bitcoin header chain is a public time-stamp of a Merkle root of transactions.

Bitcoin and its backbone. Nakamoto (2008); Garay, Kiayias, and Leonardos (2015) formalize common prefix and chain quality under a bounded-delay, honest-majority-of-resource model. BITFUC inherits that model; it does not improve the theorems.

Script and Taproot. SegWit (BIP141) and Taproot (BIP340/341/342) as shipped in Core 31.1. No new opcode is proposed.

Altcoins as reparameterizations. Most “new coins” are Bitcoin’s construction with a different genesis and, sometimes, a different puzzle or retarget. Intellectual honesty requires saying so. BITFUC is in that class. Its distinction, if any, is identification and policy: a disjoint identity, an unspendable genesis, empty seeds, and a refusal to start an unfrozen mainnet.

3. Preliminaries

3.1 Notation

Let {0,1}* be finite binary strings. Let SHA256 map such strings to 256-bit strings. Write SHA256d(x) := SHA256(SHA256(x)). Interpret 256-bit strings as integers in [0, 2²⁵⁶) in Bitcoin’s header convention. A header h meets a target T when SHA256d(h) ≤ T.

Let 𝔾 be the secp256k1 group, prime order n, generator G. Secret keys are scalars; public keys are dG. ECDSA and BIP340 Schnorr are used as specified. We treat them as EUF-CMA secure in the usual models. We do not introduce a new signature scheme.

Amounts are integers. Write COIN := 10⁸. One FUC, if the proposed parameterization is adopted, is COIN base units. Conservation is always in base units.

3.2 Cryptographic assumptions (inherited)

Assumption 1 (hash). SHA256 is collision-resistant and, for proof of work, preimage-hard on the header space: finding h with SHA256d(h) ≤ T requires Θ(2²⁵⁶/T) evaluations in expectation for random search.

Assumption 2 (signatures). Forged witnesses for secp256k1 ECDSA or BIP340 Schnorr, without the corresponding secret, are infeasible.

These are Bitcoin’s assumptions. BITFUC adds none and removes none.

4. The intermediated-money problem

Definition 1 — Account ledger. An account ledger is a map B from identifiers to non-negative integers, together with an authorized operator who may replace B by B′. A payment is the operator’s update. The right to pay is the operator’s willingness. That is the trust assumption.

Definition 2 — Bearer instrument. A pair (s, V) where s is a secret and V is a publicly checkable predicate such that knowledge of s is necessary and sufficient (under Assumption 2) to authorize a transfer of the associated units.

Electronic cash is the problem of maintaining a public V that updates without a privileged operator, while preserving conservation and forbidding double-spends.

On “alternative money”. A protocol can at most supply a candidate bearer instrument. Whether it is money is a fact about acceptance: do counterparties extinguish debts in it? That fact is empirical and, for BITFUC, presently false. There is no public chain and no observed price.

5. Transactions as a conservative rewrite system

Definition 3 — Output. A pair o = (v, π) of a value in base units and a locking script.

Definition 4–5 — Outpoint and UTXO set. An outpoint names the i-th output of a transaction. At a chain state, the UTXO set U is a finite map from outpoints to outputs. A coin is an element of U.

Definition 6–9 — Transactions. A non-coinbase transaction is conservative when the sum of input values is at least the sum of output values; the difference is the fee. An input is authorized when its witness satisfies π under Bitcoin Core 31.1 script (including SegWit and Taproot). Applying a valid transaction deletes spent outpoints and inserts new ones.

Remark 1. This is a linear rewrite system on a multiset of coins. A “balance” is a query, not a primitive.

A coinbase has no UTXO inputs. It may create outputs totaling at most subsidy(H) + fees. Those outputs are unspendable until height H + 100 (maturity).

Definition 10 — Genesis exception. The height-0 coinbase is not inserted into U. Combined with an OP_RETURN payload, it creates no spendable developer units. That is the premine policy. A later spendable genesis is a different instrument.

6. The ledger as a most-work tree

A header is 80 bytes: version, previous-header hash, Merkle root, timestamp, compact target, nonce. A block is a header plus a transaction list whose Merkle root matches, whose first transaction is a legal coinbase, and whose remaining transactions are sequentially valid. A chain is a sequence from the network’s genesis, each header committing to the previous hash.

The work of a block is, as in Bitcoin, the integer function of its target (see GetBlockProof). The work of a chain is the sum. Among validated headers, the canonical chain is a valid chain from genesis of maximal total work.

This is Nakamoto consensus. It is not voting, proof of stake, or a committee. If a heavier valid chain appears, the node reorganizes. Confirmations are a heuristic (depth under the current tip), not a finality gadget.

Remark 2. “k confirmations” means an adversary who would reverse the payment must produce a competing fork of greater work. Under an honest majority of hashrate, that probability falls exponentially in k (Nakamoto 2008, §11). The hypothesis is about hashrate, not about the number of visitors to a website.

7. Difficulty, work, and the public-net objection

Regtest uses a trivial target so that generatetoaddress succeeds on a laptop. That is a laboratory parameter.

Bitcoin’s production difficulty retargets every 2016 blocks toward a ten-minute spacing. On a new SHA-256d chain the hashrate is, for a long time, negligible relative to existing SHA-256d ASIC capital. Two consequences are not optional:

51% is cheap on SHA-256d. An adversary who already points ASICs at Bitcoin can, at small opportunity cost, outwork a hobby SHA-256d net, reorganize, and double-spend.
2016-block retargeting is a poor fit for a low, jumpy hashrate: a spike mines many blocks at an obsolete target; a drought then stalls the chain.

D1: independent RandomX, not merge-mined. Public nets compare RandomX of the 80-byte header to the target. Block identity stays SHA-256d. D2: aserti3-2d, two-minute spacing, two-day half-life, genesis anchor. Testnet also allows min-difficulty blocks. See docs/pow.md.

Remark 3. RandomX is an established CPU-oriented function, not a new hash.

8. Scripts, witnesses, and names of coins

BITFUC uses Bitcoin Core 31.1 script. Default addresses are native SegWit with disjoint human-readable parts: fuc (public), tfuc (test), fucrt (local starter). Bitcoin uses bc, tb, bcrt. Base58 and extended-key versions are likewise disjoint.

Definition 15 — Network identity. A tuple (genesis header, 4-byte magic, ports, HRP, Base58 versions, datadir). Two identities define two coins, even if the script interpreter is the same program.

User-agent /Bitfuc:0.1.0/. Configuration bitfuc.conf. Processes bitfucd, bitfuc-cli.

9. Monetary parameterization

Issuance is a function of height, not of a committee minute. D3 is written in docs/monetary-policy.md.

Hard cap: 1,000,000,000 FUC. Heights 1 through 13,140,000 (fifty 365-day years of two-minute blocks) split that cap evenly, about 76.10 FUC per block. After that, subsidy is zero. Genesis pays nothing spendable.

That is 2% of the cap per year for 50 years, then stop. It is not a 2% mint on each transfer — that would inflate forever and pay for spam. Default fee floor: 0.010 bit/vB. First confirmation targets two minutes, not ten.

On public nets, 2% of transaction fees are burned. Miners claim subsidy plus the other 98%. After issuance ends, circulating supply is flat or falling. Coinbase maturity: 100 blocks (~3.3 hours). Regtest keeps the laboratory 50 FUC schedule and does not burn fees.

Developer premine = 0. Hidden allocation is forbidden. A faucet, if any, belongs on testnet and must be labeled NO VALUE.

10. BITFUC as a specified instance

Everyday use is bitfuc-main (addresses fuc1…). How to run the test and local starter chains is on Testnet, not mixed into Get started.

Name	Role
bitfuc-regtest	Local starter chain. Identity frozen; resettable.
bitfuc-test	Public test identity. Units labeled NO VALUE.
bitfuc-main	Public parameters: 1e9 cap, two-minute ASERT, RandomX.

Magic bytes are SHA256d(UTF-8 label)[0:4]:

Network	Label	Magic	P2P / RPC
public	bitfuc-main-magic-v1	82 43 ac 07	17333 / 17332
test	bitfuc-test-magic-v1	83 30 6d c4	27333 / 27332
regtest	bitfuc-regtest-magic-v1	96 79 32 83	17444 / 17443

Regtest genesis (reproduce with python3 contrib/bitfuc/genesis.py): coinbase BITFUC regtest -- local development chain.; nTime 1755788400; nBits 0x207fffff; nonce 0; merkle bfe26f33…0a530c; hash 36dd99e4…7329d5.

Public genesis bytes live in src/kernel/chainparams.cpp. See docs/genesis.md.

DNS and fixed seeds are empty. Checkpoints and assumevalid contain no Bitcoin state. The node exposes getblocktemplate and submitblock. On regtest, generatetoaddress is the laboratory miner.

11. Implementation

Git history starts from official Bitcoin Core tag v31.1. Consensus-critical paths are not rewritten for branding. This website is static HTML. It is not a validator and does not display a tip. Wallets are descriptor wallets inside bitfucd, with a local UI on 127.0.0.1. This site is not a custodian. Programs use contrib/bitfuc/agent.py and /.well-known/bitfuc.json.

12. Security discussion

Local. On regtest, difficulty is trivial. An attacker on the same machine can rewrite the chain. That is the point of a test network.

Public. The rules are Bitcoin Core 31.1’s. What is not equal to Bitcoin is the cost of attacking this chain. Nakamoto security is an honest majority of work on this network. Bitcoin’s hashrate is enormous; FUC does not inherit it. That is why the public puzzle is independent RandomX and the DAA is ASERT — not because the C++ is weaker. See docs/pow.md.

A UTXO graph is not untraceable. A lock-and-mint bridge is a custodian. Both are out of any privacy or “wrapped FUC” claim.

13. What this paper does not establish

The following sentences are false if asserted as theorems about the world in 2026:

“BITFUC is money.”
“FUC has a market price.”
“BITFUC is a safe store of value.”
“BITFUC is as costly to 51% as Bitcoin.” (Same kernel. Different work on this genesis.)
“This website holds your keys.”
“This paper is an offering or a solicitation.”
“The authors are affiliated with MIT or any central bank.”

What the paper does establish is that a Bitcoin-derived electronic-cash construction can be instantiated with a disjoint identity and a zero-allocation genesis, and that the laboratory instance works. Whether anyone should use such an instance as money is not a lemma.

14. Further work

Already decided: money rule (D3), ASERT (D2), RandomX (D1), unspendable genesis (D4), programs as ordinary operators (D10).

Still to do: publish seeds without a single operator as a liveness dependency. Fee security after subsidy ends is open for Bitcoin too. A native market, if ever, is a book or an HTLC swap — not Uniswap pasted onto UTXO.

15. Conclusion

Nakamoto electronic cash is a conservative UTXO rewrite system whose canonical history is the most-work header chain. BITFUC is that system, identified so that it cannot be mistaken for Bitcoin, allocated so that genesis creates no developer coins, and operated so that keys stay with the node’s owner.

That is a complete description. It is less exciting than a monetary manifesto and more accurate.

Whether anyone treats FUC as money is a social and legal question, not a lemma of this paper.

Appendix A. Reproduction

python3 contrib/bitfuc/genesis.py
cmake -B build -DENABLE_IPC=OFF -DBUILD_GUI=OFF -DINSTALL_MAN=OFF
cmake --build build --target bitfuc
./scripts/regtest/acceptance.sh

cmake --build build --target bitfuc writes bitfucd / bitfuc-cli.

Appendix B. Document control

Field	Value
Canonical file	`docs/whitepaper.md`
Legal text	`docs/legal-notice.md`
Genesis table	`docs/genesis.md`
Open questions	`docs/open-decisions.md`

References

Back, A. (2002). Hashcash — A Denial of Service Counter-Measure.
Bayer, D., Haber, S., and Stornetta, W. S. (1993). Improving the efficiency and reliability of digital time-stamping. Sequences II.
Bitcoin Core developers (2026). Bitcoin Core v31.1.
Chaum, D. (1982). Blind signatures for untraceable payments. Crypto ’82.
Chaum, D., Fiat, A., and Naor, M. (1988). Untraceable electronic cash. Crypto ’88.
Dai, W. (1998). b-money.
Dwork, C. and Naor, M. (1992). Pricing via processing or combatting junk mail. Crypto ’92.
Garay, J., Kiayias, A., and Leonardos, N. (2015). The Bitcoin backbone protocol. Eurocrypt 2015.
Haber, S. and Stornetta, W. S. (1991). How to time-stamp a digital document. Journal of Cryptology.
Jevons, W. S. (1875). Money and the Mechanism of Exchange.
Lombrozo, E., Lau, J., and Wuille, P. (2015). BIP 141: Segregated Witness.
Menger, C. (1892). On the origin of money. Economic Journal.
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
Wuille, P., Nick, J., and Ruffing, T. (2020). BIP 340.
Wuille, P., Nick, J., and Towns, A. (2020). BIP 341; BIP 342.