Bitcoin 1.01: a serverless peer-to-peer currency with quantum-resistant signatures, anchored to Bitcoin

Whitepaper · Launch release · 2026

This document describes Bitcoin 1.01's format, its proof of work and its security measures beyond mining. Every number comes from a constant in the program's source code; file names are given in parentheses. The full record of design decisions is in TASARIM.md, usage is in BENIOKU.md. Commands, file and folder names are Turkish words; they are kept unchanged here so that they match the program.

Abstract

Bitcoin 1.01 is a peer-to-peer currency that keeps Bitcoin's idea: a block chain anyone can verify, the heaviest chain chosen by proof of work, a fixed and decreasing supply. It departs from Bitcoin in three places:

1. The signature and the hash are renewed against quantum computers. Transactions are signed with SLH-DSA-SHAKE-256s (NIST FIPS 205), which rests only on hash functions. Blocks are sealed with the 1024-bit ORION hash (Keccak-f[1600] with a 1024-bit capacity).
2. It needs no server. Peers find each other on their own on the same local network, and on the internet through seed addresses and address sharing. There is no domain, no hosting, no account and no identity check (KYC).
3. Part of the security is moved from the miners to Bitcoin. From time to time nodes write a block's digest to Bitcoin (an anchor). An anchor with 6 confirmations on Bitcoin protects that block even against a majority of the hash power. Whoever anchors receives half of the reward of the block they anchored.

For the launch the difficulty was raised on purpose: every block, the genesis included, needs at least 2^36 attempts (16 times Bitcoin's difficulty 1). Blocks come every 15 minutes, and the difficulty adjusts every block with the relative ASERT rule; during the first 2016 blocks a launch ramp raises the half-life from 1 hour to 12 hours, so a large miner arriving at the opening cannot collect a rain of cheap blocks. The network's opening is announced in advance, and the first block is tied to a Bitcoin block mined after the opening, so mining in secret before the opening is wasted.

All peer-to-peer connections are protected with hybrid quantum-resistant encryption (X25519 + ML-KEM-1024, Phase 6). Private messages and signed public posts, which are never written to the chain, are stored and forwarded between peers (Phase 7). The Bitcoin 1.01 Protocol (PROTOKOL.md), which runs next to Bitcoin 1.01, is a second layer backed 1:1 by burned coins: proof of stake, split into Dor Columns, final within seconds; it verifies Bitcoin 1.01's header chain as part of its own state.

1. Why Bitcoin 1.01

Bitcoin's signature (ECDSA, secp256k1) can be broken with Shor's algorithm on a large enough quantum computer. Changing Bitcoin requires agreement across its whole network. Bitcoin 1.01 tries this change as a chain built that way from the start, and stays close to Bitcoin in everything else: the UTXO model, the most-work chain rule, a supply that does not exceed 21 million, and a reward that halves every four years.

The second goal is having no server. The program depends on no website, API or central service. The bit101.org site only carries the documents and the download link; the network keeps running even if it goes away. To take part, running a program is enough. No identity, e-mail or phone number is asked for.

2. Format

2.1 Hash: the ORION family

ORION is not our own invention. It uses the Keccak-f[1600] permutation at the heart of SHA-3 with a capacity of 1024 bits and a rate of 72 bytes, the setting of SHA3-512 (src/orion.*).

A tag is put in front of every call: [length (1 byte)] "orion-stars-up-my-sleeve/" + purpose. Purposes are things like blok, islem, merkle-yaprak, adres, so a hash produced for one purpose can never be used for another.

Transparency: ORION-512 is identical to the official SHA3-512 result of the same input, and so are the first 64 bytes of ORION-1024. Anyone can check the first half of a block's hash with any SHA3-512 tool.

2.2 √2 and 3x+1

The binary expansion of √2 is computed inside the program without any library (src/kok2.*). Its first 64 bits are 6a09e667f3bcc908, the same as SHA-256's first initial constant.

• Genesis: the first 2048 bits of √2 go into the genesis record, and the first 1024 bits into the genesis's "previous hash" ("before the chain there was √2").
• Era constant: the block hash is ORION-1024("blok", header || era constant). In every halving era (140,000 blocks) the next 1024 bits of √2 become the era constant. No vote is needed; every device computes the same result.
• 3x+1: every header carries the number of steps the Collatz sequence of (height + 27) takes to reach 1. At genesis that number is 27: 111 steps, peak 9,232. It plays no role in security; it is like the chain's signature. Genesis mining also starts at nonce = 27.

√2 is not secret. No key is derived from √2.

2.3 Block header (228 bytes, little-endian)

Block = header + transaction count (4 bytes) + transactions. The body is at most 4 MB. In the Merkle tree, leaves and inner nodes are hashed with different tags; an odd node left over is not duplicated but carried up a level (so there is no CVE-2012-2459-style ambiguity as in Bitcoin).

2.4 Keys, addresses, signatures

• Signature: SLH-DSA-SHAKE-256s (NIST FIPS 205, security category 5). Public key 64 bytes, signature 29,792 bytes. The code was written from scratch and passes all of NIST's official ACVP test vectors (bitcoin101 nist-test). Signatures are "hedged": 32 bytes of fresh randomness from the operating system in every signature.
• Address = 768 bits of the output of ORION-1024("adres", public key). Text form orn + Base58(address + a 4-byte checksum), 140 characters. An address with a single wrong character is rejected.
• Wallet: a single 256-bit master secret. Every address is derived from it; a single 72-character backup (64 hex + checksum) restores them all.

2.5 Transactions

• Transaction ID (txid) = ORION-512("islem", body); signatures are not included, so the ID cannot be changed with the signature. The Merkle tree takes the full ID, signatures included.
• Inputs from the same address share a single signature; this matters because every signature is about 30 KB.
• A transaction has a note field of at most 80 bytes.
• Fee policy: 1,000 units per 1,000 bytes. A single-signature transaction is ~30 KB, its fee ~0.0003 coins. This is a pool acceptance rule, not a consensus rule.
• 1 coin = 100,000,000 units.

2.6 The Bitcoin anchor format

An anchor is a 77-byte payload written to a single OP_RETURN output on Bitcoin (within Bitcoin's standard 80-byte limit):

"B101" | network (1 byte: 0 main, 1 test) | height (8, little-endian) | digest (32) | reward (32)
digest = first 32 bytes of ORION-512("bitcoin-capasi", 1.01 block hash)
reward = first 32 bytes of ORION-512("capa-odul-adresi", 1.01 reward address)

The anchor transaction spends from a single-key P2WSH address derived from the wallet's master secret and is about 211 vB (~420 sat at 2 sat/vB). The proof in an anchor reward transaction (type 2) looks like this:

proof length (4) | Bitcoin transaction + Merkle branch + Bitcoin block ID | header count (1) = 6 | 6 × 80-byte headers

3. Proof of work and difficulty: why we made mining harder

3.1 The rules

The target is a 1024-bit number written in Bitcoin's compressed form: T = c × 256^(e−3), bits = e<<24 | c. A block is valid if its hash (read as a big-endian number) is smaller than T. The expected number of attempts is 2^1024 / T. Every block, the genesis included, is checked with the same rules (src/zorluk.*):

Canonical encoding is required: only one way of writing a target is accepted, and a sign bit or a target easier than the floor is rejected. The chain is chosen by total work, not by block count: a block's work is 2^1024 / T, computed as an integer and the same on every computer.

3.1b Launch ramp (the first 2016 blocks of relative ASERT)

A 12-hour half-life neutralises timestamp tricks on a settled network but reacts very slowly in the network's first hours. If a 20 GH/s GPU farm joins the network waiting at the floor, each block raises the difficulty by only 2^(899/43200) ≈ 1.45%; the farm mines hundreds of blocks in minutes before the difficulty catches up. So during the first 2016 blocks (~3 weeks) the half-life starts at 1 hour and rises linearly to 12 hours with every block (integer arithmetic, identical on every node). In the simulation the same farm mined 59 blocks in the first 6 hours with the ramp and 328 without it (target 24). The cost: at the start of the ramp a 1-hour timestamp trick can halve the difficulty temporarily; with relative ASERT the next honest block undoes it.

3.2 Relative ASERT

Each block's target is computed from the previous block's target and interval:

T_new = T_previous × 2^((interval − 900) / 43,200)

• The factors cancel out along the chain: after N blocks the result depends only on the total time. Unless the floor is hit, it equals absolute ASERT (measured over 2,000 random intervals: a difference of 0.01%).
• The difference shows at the floor. While the network waits at the floor, absolute ASERT builds up a "schedule debt"; when a strong miner arrives, the difficulty stays low until that debt is paid off, and cheap blocks rain down. Relative ASERT builds up no debt.
• The arithmetic is all integer: a Q62 table of 2^(2^−i) values is used for 2^x, and the result is rounded to nearest. Every device gets the same result bit for bit; none of the 65,536 fraction values overflows.
• A timestamp trick has a limited effect: pushing a timestamp to the furthest allowed point (1 hour ahead) lowers the difficulty by at most ×0.944.
• Blocks #1 and #2 are mined at a fixed target (the floor): block #1's interval is the time from genesis to the opening, which means nothing.

3.3 Why we made it harder

On the pre-launch test network the floor was 2^16 attempts. An ordinary laptop could mine hundreds of blocks in seconds, and the chain had fallen far behind schedule. The raised floor and genesis solve these problems:

1. Cheap fake chains and header spam. A node checks the proof of work of every header sent to it. With a low floor, building a fake header chain costs nothing. With the floor, every header needs at least 2^36 attempts; a fake branch costs as much as real work.
2. Meaning for the work-based rules. Measures like the deep-fork penalty, finality and the Bitcoin anchor (section 5) rest on the assumption that a block represents a certain amount of work. On a network where a hundred blocks can be mined per second, "100 blocks deep" means nothing. A node that started mining before connecting to the network could also build, in seconds, a chain deeper than the finality depth and cut itself off from the main chain.
3. A fair start. The floor makes it hard to collect blocks cheaply in the first hours. Together with the opening rules (section 6), nobody can gain an advantage before the network opens.
4. Consistent rules. The genesis is checked with the same rules as later blocks; a genesis easier than the floor would be the only block that breaks the network's own rule. The genesis has the same difficulty as the floor; its difficulty adds nothing to security; its real meaning is a starting point everyone can reproduce but nobody can choose: the nonce is the smallest valid value greater than or equal to 27.
5. 15-minute blocks. SLH-DSA signatures are large (~30 KB per transaction). For home connections and serverless propagation, less frequent blocks lower the orphan rate. At the same hash power, every confirmation carries 7.5 times more work than with 2-minute blocks. The cost is slower confirmation; anchor finality (section 5.2) reduces that cost for large payments.

3.4 Simulation and the honest cost

araclar/zorluk_test.cpp (and bitcoin101 test section 7) simulates a scenario where hash power changes, using the rules themselves. Block intervals are drawn from an exponential distribution:

• The floor is a cost. On a small network made only of processors, blocks come slower than 15 minutes: a processor doing 8 million attempts per second finds a block at the floor about every 2.4 hours on average. For the network to settle at 15 minutes, its total hash power must be at least ~76 MH/s (2^36 / 900 s).
• The genesis is mined once. At 8 million attempts per second it takes ~45 hours on average. Luck plays a big part: even odds of under 31 hours, a 5% chance of over 134 hours. Mining resumes where it stopped; the result does not depend on interruptions or the number of cores.
• GPUs and special hardware. ORION is not a memory-hard hash; GPUs and, later, special circuits will be faster than processors. This was accepted on purpose: anyone can mine with any hardware, and ASERT settles at 15 minutes at every level of hash power. Today the program ships only a processor miner.

4. Monetary policy

The anchor share does not increase the supply; it is set aside from the miner's reward. The miner of a block whose height is a multiple of 4 receives 37.5 coins and whoever anchors that block receives 37.5 coins; in other blocks the miner receives all 75 coins. A share not claimed within a week (672 blocks) is never minted, and the supply stays below 21 million. A reward transaction can write at most miner reward + fees.

5. Security beyond mining

No proof-of-work chain can be fully protected against someone who takes over the majority of the hash power; Bitcoin cannot either. Bitcoin 1.01's measures make an attack expensive, limit its damage, warn the user in time and tie part of the security to Bitcoin's proof of work.

5.1 Security coefficients

Consensus rules (every node applies them the same way; a block that breaks one is invalid):

Node policies (each node's own decision; against chains mined in secret and published all at once):

What the deep-fork penalty means: if the attacker's share of the hash power is q, undoing d blocks requires q/(1−q) ≥ d/6. That is 67% for 12 blocks, 83% for 30 blocks, 91% for 60 blocks; deeper than 100 is automatically impossible.

Cryptography:

Network: at most 8 outgoing and 64 incoming connections, at most 4 from one IP; messages at most 6 MB; a peer silent for 180 seconds is closed; a peer that sends an invalid block, header or transaction is banned for an hour; at most 120 transactions per minute are checked from one peer; outgoing connections made with addresses learned from peers pick at most one peer per /16 network group (against eclipse attacks). Errors independent of state (a broken signature, someone else's output, a broken Bitcoin proof) are violations. Errors that come from state (no such output, not yet mature, a different branch) are not.

5.2 The Bitcoin anchor

A node writes the digest of a block on its chain to Bitcoin. Once the Bitcoin block is confirmed, it is proof, protected by Bitcoin's proof of work, that "on the 1.01 chain, block #h existed no later than Bitcoin #X". The proof (raw transaction + Merkle branch + Bitcoin block) spreads to peers. Every node verifies it against its own Bitcoin header chain; that chain starts from a real Bitcoin block built into the program (a checkpoint) and applies all of Bitcoin's header rules. No one has to be trusted.

• Veto: if a fork would undo a block on our chain whose anchor has 6 confirmations on Bitcoin, and the new branch was not anchored before us, the branch is rejected, whatever its amount of work. The veto never moves the node to a chain with less work; it only rejects.
• Anchor finality: transactions below an anchored block show as "Final · anchor" in the app. At the suggested rate (every 4 blocks, at least 6 blocks behind the tip, 6 confirmations on Bitcoin) a transaction gets there in about 2.5–3.5 hours. With the work rule alone it would take 100 blocks (~25 hours).
• Honest limit: the veto does not stop an attacker who also anchors their secret branch early; the work rules still apply. But their anchor leaves a trace on Bitcoin that anyone can see: watchers (araclar/capa_gozcu.py) find it, the network warns of a "conflicting anchor" and finality stops.

Other methods considered: merged mining (not possible: a different proof of work), finality with stake-holding validators (needs stake locking, slashing and ~30 KB vote transactions; at launch stake sits with a few people, so it was deferred), release checkpoints (added after launch).

5.3 The anchor reward

An anchor is cheap (~420 sat), but someone has to keep making it. The reward takes this job from one person's good will and ties it to the network's rule:

1. Half of the reward of block #h, when h is a multiple of 4, is set aside not for the miner but for whoever anchors #h to Bitcoin. The anchor payload carries the digest of the 1.01 address the reward goes to. The program that makes the anchor writes the wallet's first address.
2. Once the anchor has 6 confirmations on Bitcoin, the anchorer's program builds and relays an anchor reward transaction (type 2). It contains the anchor transaction, the Merkle branch and 6 headers from Bitcoin (the anchor block and the 5 blocks after it).
3. Every node checks this transaction independently of the chain. The headers must be consecutive, each with a valid proof of work, and each must meet the network's Bitcoin difficulty floor (target ≤ 2^182, i.e. Bitcoin difficulty ≥ ~4.4 trillion; ~1/32 of the difficulty in 2026). The Merkle branch must reach the first header, the payload must carry the digest of block #h and the digest of the output address, and the amount must be exactly the share.
4. Miners also check that the claim's Bitcoin block has 6 confirmations in their own Bitcoin header chain (policy).
5. At most one reward is paid per block on the chain; the first one in wins. The claim must enter the chain no later than 672 blocks (~1 week) after #h, and the Bitcoin block must be at most 12 hours after the time of #h.

The cost of a fake claim: for an anchor that is not in the Bitcoin header chain, 6 headers have to be mined at the floor difficulty. That is ~19% of the work of one of today's Bitcoin blocks, work worth ~0.6 BTC of mining income. A real anchor costs ~420 sat. A fake claim is always more expensive than an honest anchor. If the value of 1.01 rises, the floor can be raised without invalidating old blocks (a soft fork).

Why half: the miner produces proof of work every block; the anchorer writes a proof to Bitcoin once an hour. Half of the reward keeps the anchor transaction profitable even when Bitcoin fees are high. The total cost is capped at 1/8 of the supply. If nobody anchors, nothing passes to the miner and that share is never minted, so miners have no reason to prefer an unanchored chain.

5.4 The bridge

Swaps with Bitcoin are done with HTLC atomic swaps: no vault, no intermediary, no server. Either both sides get what they were promised or both get their own money back. While the network is small, a swap's security is only as strong as the hash power on 1.01, so a swap with real BTC is limited to at most 0.01 BTC.

6. Opening the network and the genesis

The genesis is produced entirely from constants, and everyone gets the same result:

The genesis's difficulty adds nothing to security: the nonce is deterministic, whoever mines it with whatever hardware finds the same result, and everyone verifies it with a single hash. The previous value (0x7C00DA73, ~1.29 trillion attempts) could take weeks on a home computer, so the genesis was lowered to the network's floor, the minimum work of every later block.

Nobody can choose the nonce: the search starts at 27 and ends at the first valid value. Mining uses many cores, but the pieces are handed out in order and the search does not stop before every smaller piece is finished. The result does not depend on the number of cores or on interruptions; anyone can mine again and find the same nonce. The value found is checked again with a pure Python Keccak implementation independent of the C++ code (araclar/genesis_dogrula.py). The first half of the hash can also be compared with any SHA3-512 tool. The program shows the nonce and the hash: bitcoin101 genesis.

Opening: the network's opening time is announced in advance, and block #1's time cannot be earlier. A timestamp alone does not stop pre-mining: someone could build up work in secret before the opening, put the timestamps after it and publish the chain at the opening. The rule that closes this is the launch anchor: the note of block #1's reward transaction must be btc:<Bitcoin block ID>, and nodes check with their own Bitcoin header chain that the Bitcoin block really exists and that its time is after the opening. That block cannot be known before the opening, so work done before the opening is wasted. The miner program writes the note itself: it waits for the first Bitcoin block mined after the opening.

No pre-mine, no developer share. The genesis has no spendable output; the first coins are mined from block #1 on, with the same rules as for everyone.

7. Encrypted network (Phase 6)

Every TCP connection is encrypted with a three-message handshake before the first O101 message (src/sifreli_kanal.*). The session key is derived from four shared secrets; if one breaks, the others still protect it:

The key encapsulation mechanism authenticates without a signature: someone without the static decapsulation key cannot find ss_ks, and the first encrypted record does not decrypt. Records are encrypted with ChaCha20-Poly1305 (the length is authenticated as associated data, a separate key per direction, rekeyed every 2^20 records). The listening node's identity is dugum_kimligi.dat in the data folder; its fingerprint is shown by bitcoin101 davet and pinned in tohumlar.txt as IP:port#iz=<64 hex>. A pinned seed that answers with another fingerprint is not connected to; for unpinned addresses the first fingerprint seen is remembered and a change raises a warning. The peer protocol rose to 4; unencrypted connections are not accepted.

X25519 (RFC 7748) and ML-KEM-1024 (FIPS 203) were written from scratch. ML-KEM is checked against all 80 of NIST's official ACVP vectors (key generation, encapsulation, decapsulation including implicit rejection, key checks), X25519 against the RFC 7748 vectors and an independent library. Measured: one handshake (two encapsulations, two decapsulations, three X25519) takes ~1 ms.

8. Messaging and archive (Phase 7)

Three kinds of objects spread between peers (src/mesaj.*). None of them is written to the chain, pays a fee or is a consensus rule.

• Card (message identity): an ML-KEM-1024 key derived from the wallet's master secret. The message address is the key's 32-byte fingerprint (omj + Base58). A card can optionally be signed with SLH-DSA by the wallet address. The backup does not change.
• Envelope (private message): a secret encapsulated to the recipient's key → ORION-512 → ChaCha20-Poly1305. Content, sender and signature are encrypted. Visible from outside: the bucket (first byte of the recipient's fingerprint; one of 256), the time, the lifetime (at most 7 days) and the size rounded to 256 bytes. The sender can add an SLH-DSA signature; the recipient verifies the sender's Bitcoin 1.01 address. While the recipient is offline the message is kept by peers (store and forward).
• Post (archive): a public text (at most 16 KB) signed with SLH-DSA by the author's wallet key. Ordinary nodes keep it 30 days, archive nodes (--arsiv) indefinitely. Optional √2 dictionary encoding: each 18-bit piece is written as the position where it first appears in the first 2^21 bits of √2 (2-bit type + 21-bit position). This is not compression (~28% longer) and not encryption; it is a symbolic form that carries the chain's √2 signature. The dictionary file ships with the program and its ORION-512 digest is built into the code.

Spam protection: every object carries an ORION-512 proof of work (20 zero bits, +1 bit for every doubling above 4 KB); at most 200 objects per minute are accepted from a peer; when the store quota (default 256 MB, 4 GB on archive nodes) is exceeded, the object that expires first is deleted. Objects spread by inventory (NESNE_ENV / NESNE_ISTE / NESNE), so an object is downloaded once per connection. Commands: mesaj adres | gonder | oku, ilan yaz | liste | oku.

9. The link to the Bitcoin 1.01 Protocol

The Bitcoin 1.01 Protocol (PROTOKOL.md, separate program protokol101) is a second layer that uses the same cryptography and the same wallet: proof of stake with BFT finality, 16 Dor Columns, 4-second slots, one-time hash-based keys and key pre-commitment. The two chains are linked like this:

• Burn bridge (one-way, 1:1): bitcoin101 protokole-yak <p101 account> <amount> sends coins to a provably unspendable address (ORION-1024("adres", a fixed 38-byte text); since an SLH-DSA public key is 64 bytes, no secret key can spend it) and writes P101:<account> in the note. The Protocol mints the same amount. The Protocol's supply can never exceed what was burned on Bitcoin 1.01; there is no pre-mine.
• Header chain: Protocol validators put Bitcoin 1.01 headers into Protocol blocks; the Protocol verifies them with Bitcoin 1.01's own rules (proof of work, relative ASERT with the ramp, MTP, 3x+1). A burn claim is valid only after 100 confirmations.
• Heartbeat: the Protocol's epoch seed mixes the validators' RANDAO reveals with Bitcoin 1.01's proof-of-work tip hash.
• One backup: Protocol keys are derived from the Bitcoin 1.01 wallet's master secret; the same paper backup recovers both.

A user can use both together or either one alone. Bitcoin 1.01's consensus rules do not depend on the Protocol: if the Protocol stops, Bitcoin 1.01 is not affected.

10. Honest limits

• Someone who takes over the majority of the hash power can censor new transactions; the measures in section 5 only make rewriting the past harder.
• Most measures are node policies. A node cut off from the network for longer than 100 blocks does not return to the main chain by itself; a manual decision is needed. A node syncing from scratch takes the first valid chain it sees.
• For the anchor reward, the first one in wins. A miner can leave out other people's claims and put in the claim of its own (real) anchor. This does not harm security (the block is anchored either way), but it affects who gets the reward.
• At launch the network is small; on a network of processors, blocks come slower than 15 minutes.
• The cryptography of Phases 6–7 (X25519, ML-KEM-1024, the message envelope) passes the official test vectors but has not had an independent audit. Message metadata (bucket, time, size, which node it spread from) is not hidden; on unpinned peers interception is possible on the first connection (trust on first use). Messaging is on the command line for now; adding it to the app window is the next step.
• There is no real Android app package. The program carries no code signature (Authenticode); a release is verified with SHA-256 digests and an SLH-DSA file signature.
• The Bitcoin side of the bridge is ECDSA and not quantum-resistant. Its keys are new for every swap and used for a few hours.
• The science layer (BILIM_KATMANI.md) is a draft and is not part of the consensus rules.

Appendix: parameter summary

Verification: bitcoin101 test (278 checks, Phases 6–7 included), bitcoin101 nist-test, bitcoin101 fuzz, araclar/zorluk_test.cpp, araclar/genesis_dogrula.py; end to end, against a real Bitcoin Core 31.1 regtest, araclar/capa_testi.py (44/44) and araclar/kopru_testi.py (41/41), and for the app araclar/uygulama_testi.py (44/44).