Contents

Abstract

A purely peer-to-peer version of electronic cash allows online payments to be sent directly from one party to another without going through a financial institution. Alpha Blockchain implements that design to Bitcoin's exact specification — SHA-256d proof-of-work, 21,000,000-coin supply, 10-minute blocks, UTXO accounting, a full stack-machine Script engine, SegWit and Taproot — and extends it with a deterministic OP_RETURN meta-protocol layer: tokens, a DEX with AMM pools, identity, NFTs, domains, real-world assets, oracles, escrow, lending and enterprise records, all validated by every full node. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work — and it keeps running even on a local network with no internet, thanks to UDP peer discovery.

1. Introduction

Commerce on the internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. The system works well enough for most transactions, but it still suffers from the inherent weaknesses of the trust-based model: mediation costs, minimum practical transaction sizes, chargeback fraud, and the loss of non-reversible payments for non-reversible services.

Bitcoin showed what is needed instead: an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly without a trusted third party. Alpha Blockchain takes that design and rebuilds it from first principles — a clean-room, dependency-free Python implementation that mirrors Bitcoin's consensus behavior — while adding the infrastructure modern applications actually need: a deterministic token layer, a block explorer, developer APIs and the plumbing for DeFi, identity, real-world assets and enterprise use.

The project has two goals:

• Faithfulness — replicate Bitcoin's consensus-critical behavior exactly: the same header format, difficulty math, sighash algorithms, Script semantics and monetary schedule, audited against Bitcoin's real known-answer vectors.
• Usability — expose everything developers need (RPC, REST, PSBT, descriptors, tokens, explorer) so the chain is a platform, not just a coin.

2. Transactions

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner, and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.

The problem, of course, is that the payee can't verify that one of the owners did not double-spend the coin. A common solution is a trusted central mint that checks every transaction — but then the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.

We need the payee to know the previous owners did not sign any earlier transactions. The only way to confirm the absence of a transaction is to be aware of all transactions — so transactions must be publicly announced, and participants must agree on a single history of the order in which they were received. Alpha solves this exactly as Bitcoin does: a peer-to-peer distributed timestamp server generating computational proof of chronological order. In the UTXO model this takes concrete form: every node maintains the set of unspent outputs and rejects any input that references an output already spent.

3. Timestamp Server

The solution begins with a timestamp server: it works by taking a hash of a block of items to be timestamped and widely publishing the hash. The timestamp proves the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain — with each additional timestamp reinforcing the ones before it.

4. Proof-of-Work

To implement a distributed timestamp server on a peer-to-peer basis, Alpha uses a proof-of-work system similar to Adam Back's Hashcash — the same construction Bitcoin uses. The proof-of-work involves scanning for a value that, when hashed with SHA-256d (double SHA-256), gives a hash below a numeric target. The average work required is exponential in the difficulty and can be verified by executing a single hash.

Miners increment a nonce in the block until a value is found that gives the block's hash the required target. Once the CPU effort has been expended to satisfy the proof-of-work, the block cannot be changed without redoing the work — and as later blocks chain after it, changing it would mean redoing all the blocks after it.

Proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote: the majority decision is the chain with the greatest invested proof-of-work.

4.1 Consensus rules (every node enforces)

• 80-byte block header: version(4) | prev_hash(32) | merkle_root(32) | time(4) | bits(4) | nonce(4)
• Block valid iff SHA256d(header) ≤ target where target = bits_mantissa × 2^(8·(bits_exponent−3)) (bit-exact).
• Merkle root uses Bitcoin's duplicate-last rule; witness commitments (BIP141) verified.
• Median-time-past over 11 blocks (MTP) — miners can't jump the clock arbitrarily; future timestamps limited to +2 hours.
• Best chain = most cumulative chainwork (not merely longest). Reorgs disconnect and reconnect blocks with full UTXO/mempool/meta-protocol undo.
• BIP34: block height in coinbase; genesis reward unspendable (Bitcoin quirk preserved).

4.2 Difficulty retarget

To compensate for increasing hardware speed and varying interest in mining, the difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases:

5. Network

The steps to run the network — identical to Bitcoin's:

1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into a block.
3. Each node works on finding a difficult proof-of-work for its block.
4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
5. Nodes accept the block only if all transactions in it are valid and not already spent.
6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.

Nodes always consider the chain with the most work to be the correct one and keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, nodes work on the first one they receive but save the other branch in case it accumulates more work; the tie is broken when the next proof-of-work is found. Broadcasts are tolerant of dropped messages — a node that misses a block requests it when it realizes it missed one.

5.1 Wire protocol & discovery

• Wire protocol: Bitcoin-exact framing — magic, 12-byte command, sha256d checksum, 32MB cap
• Handshake: version/verack, sendheaders, sendcmpct
• Sync: headers-first + getblocks + inv/getdata relay
• Compact blocks (BIP152): short-ID reconstruction from mempool
• Bloom filters (BIP37): filterload/add/clear + filtered-block serving
• Compact filters (BIP157/158): GCS block filters
• addrv2 (BIP155), SOCKS5 proxy, Tor hidden service
• Pruning (keep-N blocks) + assumeutxo snapshot sync
• 24 message handlers covering the full message set
• Seed nodes: new nodes auto-connect to public seeds (68.178.163.58:8333) — no manual peering needed, like Bitcoin's DNS seeds
• LAN discovery: nodes broadcast UDP beacons on port 8334 — peers on the same local network auto-connect, so the chain keeps syncing even without the public internet
• Offline capable: a node mines, signs and validates standalone; transactions can be signed offline and broadcast on reconnect

6. Incentive

By convention, the first transaction in a block is a special transaction — the coinbase — that creates new coins owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant amount of new coins is analogous to gold miners expending resources to add gold to circulation — in our case, CPU time and electricity are expended.

The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a fee added to the incentive value of the block containing the transaction. Once the predetermined number of coins has entered circulation, the incentive transitions entirely to transaction fees and becomes completely inflation-free.

The incentive also encourages nodes to stay honest. If a greedy attacker assembles more CPU power than all honest nodes, he must choose between defrauding people by stealing back his payments, or generating new coins. He ought to find it more profitable to play by the rules — rules that favor him with more new coins than everyone else combined — than to undermine the system and the validity of his own wealth.

7. Monetary Policy

Issuance converges on the same asymptote as Bitcoin: the sum of all future block rewards is a geometric series approaching but never reaching its cap.

7.1 Community Reserve — 25%

5,250,000 ALPHA (25% of total supply) is allocated to a community reserve governed by a 3-of-5 multisig address — five founding members, any three required to spend. No single member controls the fund; it is released for ecosystem growth, listings, development and member benefit as the community decides.

The remaining 15,750,000 ALPHA (75%) enters circulation strictly through the Bitcoin-style mining schedule — fair, permissionless, earned by work.

7.2 Provable Burning

ALPHA supports verifiable coin destruction via the burnalpha RPC: coins are sent to an OP_RETURN output, which is unspendable by consensus — the same mechanism Bitcoin users employ to provably remove coins. Anyone can verify a burn on-chain; burned coins permanently reduce circulating supply.

8. Reclaiming Disk Space

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle tree, with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree — the interior hashes do not need to be stored.

A block header with no transactions is about 80 bytes. With blocks every 10 minutes, that's 80 × 6 × 24 × 365 ≈ 4.2 MB per year — storage is not a problem even if all headers are kept in memory. Alpha additionally supports keep-N pruning and assumeutxo snapshot sync for nodes that want to start fast or stay small.

9. Simplified Payment Verification

It is possible to verify payments without running a full network node. A user only needs a copy of the block headers of the most-work chain — obtainable by querying network nodes — plus the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction himself, but by linking it to a place in the chain he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

The verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker — a light client can be fooled by fabricated transactions for as long as the attacker can overpower the network. Businesses receiving frequent payments should run their own full nodes for independent security and quicker verification. Alpha exposes gettxoutproof/verifytxoutproof (partial-merkle proofs) plus BIP157/158 compact filters for exactly this class of client.

10. Combining & Splitting Value

Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there is either a single input from a larger previous transaction, or multiple inputs combining smaller amounts — and at most two outputs: one for the payment and one returning the change, if any, back to the sender.

Fan-out — where a transaction depends on several transactions, and those depend on many more — is not a problem: there is never the need to extract a complete standalone copy of a transaction's history.

11. Privacy

The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes that method — but privacy can still be maintained by breaking the flow of information in another place: keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone — similar to stock exchanges publishing the time and size of trades (the "tape") without naming the parties.

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner — if the owner of a key is revealed, linking could expose other transactions of the same owner. Alpha's HD wallet (BIP32) derives a fresh address per receive for exactly this reason, and Tor/SOCKS5 support hides network-level identity.

12. Script & Contracts

A complete Bitcoin-style stack interpreter executes every standard locking script:

• Legacy: P2PK, P2PKH, P2SH, m-of-n multisig, OP_RETURN
• Timelocks: CLTV (BIP65), CSV (BIP112)
• SegWit v0: P2WPKH, P2WSH, P2SH-P2WPKH (BIP141/143/144)
• Taproot (BIP340/341/342): schnorr signatures, key-path & script-path spends, tapleaf merkle trees, control blocks, OP_CHECKSIGADD
• Full sighash matrix: ALL/NONE/SINGLE/ANYONECANPAY across legacy, BIP143 and BIP341
• Policy flags: STRICTENC, DERSIG, LOW_S, NULLDUMMY, NULLFAIL, CLEANSTACK, MINIMALIF, MINIMALDATA, WITNESS_PUBKEYTYPE

On top of these primitives sit HTLC atomic swaps (hashlock + timelock contracts) enabling trustless exchange with Bitcoin-family chains.

13. The Meta-Protocol Layer

Alpha's extension over Bitcoin's design: application protocols encoded in OP_RETURN outputs (Omni-style). Base consensus stays untouched — every node replays the ops in block order into a deterministic parallel indexer, journaled for reorg safety. Invalid ops (over-balance sends, non-issuer mints, expired escrows) are ignored by every node identically, so all honest nodes converge on the same application state.

Protocol	Operations (live)
Tokens — ALP	issue, send, mint, burn; registry + holder lists; KYC-gated RWA tokens with clawback, dividends, physical-backing records, carbon retirement
DEX	on-chain order book: dexsell, dexfill, dexcancell, dexswap (market buy with best-price execution), max-cost slippage caps
AMM pools	constant-product x·y=k pools: create, add/remove liquidity (LP shares), quote, swap with min_out; 0.3% fee
Identity	did:alpha:<address> registration/resolution, verifiable credentials (issue/verify/revoke), Alpha ID sign-in challenges, reusable on-chain KYC status
Web3	NFT mint/transfer/burn, NFT marketplace escrow (list/buy), .alpha domain register/resolve/transfer, on-chain gaming achievements
Oracle & AI	data feeds (create/publish/latest/history) signed by publisher key, AI-agent registry, machine-to-machine payment receipts
Escrow & lending	3-party escrow (release/dispute/refund/expiry-claim), collateralized token loans with interest and default seizure
Merchant	invoices + payment links + paid-status tracking (createinvoice/payinvoice/listinvoices)
Enterprise	supply-chain items/events/history, tamper-evident certificates (issue/verify/revoke), business registry
Atomic swaps	HTLC initiate/participate/redeem/refund for cross-chain exchange

14. Wallet & Keys

• Encryption: AES-256-CBC + SHA-512×25000 EVP_BytesToKey (encryptwallet/unlock/lock)
• HD: BIP32 deterministic keys (xprv/xpub, hardened/normal, BIP39 seed)
• Addresses: legacy, P2SH-segwit, bech32 P2WPKH, bech32m taproot
• Signing: coin-select + change, all script types, signmessage/verifymessage
• PSBT: BIP174 fund/sign/finalize + BIP380 descriptors
• Web wallet: browser-side key generation + signing (secp256k1/ECDSA in JS), AES-GCM localStorage, QR payments — keys never leave the device

15. Security Model & Calculations

• RFC6979 deterministic nonces — no nonce reuse → no key leakage
• Strict DER (BIP66) + low-S (BIP62) — signature malleability closed
• Curve validation on all pubkeys; off-curve keys rejected
• Cookie-auth RPC (bitcoind model), wallet file 0600, no eval/exec/pickle/subprocess
• All consensus bounds enforced: MAX_MONEY, negative/zero outputs, double-spend, fee≥0, maturity
• Pure-Python crypto — no external dependencies to attack

15.1 Attack probability — how safe are z confirmations?

Following the Bitcoin whitepaper's analysis: consider an attacker trying to generate an alternate chain faster than the honest chain. The race is a Binomial Random Walk — honest block found: gap +1; attacker block found: gap −1. The probability of an attacker catching up from z blocks behind is the Gambler's Ruin result:

Since the attacker's progress is a Poisson distribution with expected value λ = z·q/p, the probability he can ever catch up after z confirmations is:

Attacker share q	z for P < 0.1%
10%	5 confirmations
15%	8
20%	11
25%	15
30%	24
40%	89
45%	340

Against a 10%-hashrate attacker, 6 confirmations gives ~0.02% reversal probability — the same margin Bitcoin users rely on. Even a successful attacker can only try to reverse his own payments: he cannot create coins from thin air or take money that never belonged to him, because honest nodes reject invalid transactions regardless of proof-of-work.

16. APIs & Interoperability

• JSON-RPC: ~65 bitcoind-compatible methods across chain/wallet/mining/tx/tokens/PSBT/descriptors/filters + all meta-protocol methods
• REST: /rest/chaininfo|block|tx|headers|mempool|utxo|tokens
• Web/explorer API: /api/stats|blocks|block|tx|address|tokens|dexorders|search
• SPV: gettxoutproof/verifytxoutproof partial-merkle proofs
• P2P: full Bitcoin message set (24 handlers)
• SDK: alpha_cli client, PSBT + descriptors, developer docs

17. Governance & Distribution

Item	Detail
Issuance model	75% (15,750,000 ALPHA) released strictly through proof-of-work mining on the Bitcoin schedule — earned by work, no ICO, no dev fee. 25% (5,250,000 ALPHA) allocated to a community reserve locked in a 3-of-5 multisig: no single party controls it.
Emission	50/block → halves every 210,000 blocks.
Consensus changes	Soft-fork style: new rules tighten (never loosen) — nodes opt in.
Token issuance	Permissionless: any project can issue an ALP token on-chain.
Reserve governance	3-of-5 P2SH multisig — five founding members, any three signatures required; every spend is publicly auditable on-chain.

18. Use Cases

18.1 ALPHA — the coin

18.2 Alpha — the blockchain platform

19. Roadmap

• Complete: consensus, coin, script, segwit+taproot, network (incl. LAN discovery + offline mode), wallet (CLI + web), explorer, APIs, Tor, pruning, filters — and the full meta-protocol layer: tokens, DEX, AMM, atomic swaps, identity/DID/KYC, RWA, NFT/domains/gaming, oracle/AI agents, escrow/lending, merchant invoices, enterprise records, testnet faucet.
• Planned: mobile wallet apps, staking, fiat-backed stablecoin, Lightning-style payment channels.

See roadmap.html for live milestone status.

20. Technical Reference

20.1 Block header (80 bytes)

20.2 Signature hashes

20.3 Difficulty & work

20.4 Subsidy

20.5 Attacker catch-up (Gambler's Ruin + Poisson)

20.6 References

• S. Nakamoto — "Bitcoin: A Peer-to-Peer Electronic Cash System" (2008); sections 2–11 of this document follow its analysis directly
• W. Dai — b-money (1998); A. Back — Hashcash (2002); Merkle (1980); Haber & Stornetta (1991)
• BIP141/143/144 (segwit), BIP152 (compact blocks), BIP157/158 (filters), BIP155 (addrv2), BIP32/39 (HD), BIP340/341/342 (taproot), BIP174/380 (PSBT/descriptors), BIP65/112 (timelocks), BIP62/66/147 (malleability), BIP34 (coinbase height)

21. Conclusion

We have built a system for electronic transactions without relying on trust. Starting from the usual framework of coins made from digital signatures — which provides strong control of ownership but is incomplete without a way to prevent double-spending — Alpha uses a peer-to-peer network with proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change, as long as honest nodes control a majority of CPU power.

The network is robust in its unstructured simplicity. Nodes work all at once with little coordination; they need not be identified, since messages are delivered on a best-effort basis. Nodes can leave and rejoin the network at will — accepting the proof-of-work chain as proof of what happened while they were gone — and can keep transacting on a local network even when disconnected from the wider internet. They vote with their CPU power, expressing acceptance of valid blocks by extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives are enforced with this consensus mechanism — and above that shared foundation, the OP_RETURN meta-protocol layer turns Alpha from a coin into a platform.

22. Disclaimer

This document describes the Alpha Blockchain implementation as built. ALPHA is a digital asset — not legal tender, not a security, and not an investment product. Cryptocurrency involves risk; do your own research. Nothing here constitutes financial advice.

— Alpha Blockchain · engineered to the Bitcoin specification · v2.0 —