Hashstone: A Collection
Drawn from Bitcoin's First Blocks

1.Introduction

The first 10,000 blocks of the Bitcoin chain were mined between January and April 2009. Their headers are public, short and fixed: a hash, a merkle root, a time, a nonce, and in each block a coinbase transaction. Nothing about them can be changed without redoing the proof-of-work of every block that followed.

Hashstone uses these fixed values as the input to a program. The program turns the header of a block into a three-dimensional crystal, and the crystal is the work. Because the input is public and the program is inscribed on-chain, any work can be redrawn from the chain alone, and anyone can check that a work is the one its block produces.

The same release of Bitcoin contained the file market.h, which gave every user three lists of atoms: received, new, and passed on [1]. The token described in §9 takes its name from these fields. It is distributed to the works, block by block, rather than to a list of addresses chosen by the project.

2.Crystals

Each crystal is computed from data of its block: its hash, its merkle root and its coinbase. The block's data is also written on the crystal's faces. Block 0, the genesis block, is not part of the collection; it is drawn at the centre of the Orbit and is never minted.

Four inscriptions are written to the chain before the mint:

• the Seal (§4);
• a font, used to write block data on the faces;
• the generator, the program that turns block data into a crystal;
• the collection record, which marketplaces read: the supply, the rarities, the Seal and the royalty.

Each minted crystal is an inscription of about 1.2 kB of HTML. It contains the block's data and loads the generator and the font from their inscriptions by their origins. A crystal therefore depends on nothing outside the chain.

3.Rarity

Rarity is decided only by facts of the chain. A block takes the first tier whose rule it meets, from Mythic down. Each tier is rendered in its own stone.

4.The Seal

Before the mint, the project published one hash that commits to everything the collection depends on. The Seal is the SHA-256 of five section hashes:

seal = SHA-256( chain ‖ generator ‖ rarity ‖ images ‖ draw )

• chain: the headers of blocks 0 to 10,000;
• generator: the source of the program that draws a crystal;
• rarity: the rules, the names, and the tier of each of the 9,999 blocks;
• images: the SHA-256 of each of the 9,999 pictures;
• draw: the rule in §6.

The Seal is 0xb7cc69a5619a02d313b95349cba8c05e3877f6ef46f847560daaa106f087d078. It is inscribed on-chain and written into the collection record. The market page recomputes it in the reader's browser from the published file. A change to any part after the Seal was published produces a different hash.

5.The Mint

A mint requires a GitHub account at least 30 days old. This limits the number of accounts one person can use cheaply; it does not prevent it. Each account may mint 10 crystals. The first is free and each after it costs 0.035 BSV.

A mint is a ticket: a transaction carrying an output of the form

OP_FALSE OP_RETURN "hashstone" "mint" <recipient> <order id>

For a paid mint the minter's wallet creates the ticket and pays the price to the treasury in the same transaction. For a free mint the project creates the ticket. The recipient is an address the minter's wallet derives for that crystal. A ticket that does not pay the full price to the treasury, or that names another order, is refused.

6.The Draw

A crystal is assigned when the block containing the ticket is mined. Let B be the hash of that block and T the id of the ticket transaction. The pool P is the list of blocks 1 to 9,999 not yet minted, in ascending order.

seed    = SHA-256( B ‖ T )
crystal = P[ seed mod |P| ]

Tickets mined in the same block are drawn in their order within the block. The block hash is unknown to the minter and to the project when the ticket is broadcast, so neither can choose the outcome. A miner could withhold a block whose hash gives a result it dislikes, at the cost of the block reward. The draw is computed again by the minter's browser from the block hash and the ticket, and shown before the crystal is revealed.

After the draw, the project inscribes the crystal to the recipient address. The recipient's wallet then files it, so the wallet shows it and can sign for it.

7.The Market

Crystals are traded with the OrdLock contract of the 1Sat Ordinals standard. An owner lists a crystal by locking it to a script that releases it to any transaction paying the owner the listed price; the owner can cancel the listing with their own key. A purchase pays the seller and moves the crystal in one transaction. No party holds the crystal or the payment in between.

On the Hashstone market the buyer also pays a royalty of 6% of the price to the treasury, in the same transaction. The royalty is written in the collection record. Other 1Sat markets may list Hashstones and decide for themselves whether to pay it.

The Hashstone market opens trading when all 9,999 crystals are minted. Until then a crystal can be held and sent.

8.Ownership and Keys

A crystal is locked to a key of its owner's wallet. The project holds no key that can move a minted crystal, cancel a listing, or take a payment. The treasury is the creator's wallet; it receives the mint price and the royalties. A separate wallet on the project's server pays the network fees of free tickets and of inscribing each crystal, and holds only the small amount needed for that.

9.$ATOMS

$ATOMS is a BSV-21 token with a supply of 21,000,000 and no decimals. The whole supply is created inside one contract by its deploy transaction; no wallet holds it at any time. Of the supply, 14,698,012 atoms can be claimed by the crystals, up to 6,300,000 go to the pool, and the remaining 1,988 are burned.

The contract is deployed when the last of the 9,999 crystals is minted, and not before. The deploy fixes four values for good: the token id, the claim price, the block after which the claim closes (the deploy block plus 4,320, about 30 days), and the co-signer's public key. Allocations are not among them. A crystal's tier is computed from its block (§3) and sealed with the other rules (§4), so every allocation in the table below is already determined, and the contract's claim table is that list written as 9,999 bytes.

Each crystal may buy the allocation of its tier once. The allocation belongs to the block, not to the wallet: whoever holds the crystal when it claims receives the atoms.

The claim price p, in satoshis per atom, is the same for every crystal. It is fixed in the contract when the contract is deployed, so that 21,000,000 atoms at p are worth $25,000 at the BSV rate of that day. A Mythic crystal's allocation then costs about $20 and a Common crystal's about $1.25.

10.The Claim and the Burn

The contract keeps a table of 9,999 bytes, one per block: the block's tier while it is unclaimed, zero after. A claim for block h is a transaction that spends the contract and creates, in order: the contract with byte h set to zero, the bank with the payment added, and an output carrying the atoms to the buyer. The script checks each of these; a transaction that pays less, takes more, or claims a block twice is invalid.

A script cannot see who holds a crystal. Before a claim, the holder signs a request with the key that holds the crystal, naming the block, the address that will receive the atoms, and the crystal's current output. The co-signer (§12) checks this signature against the chain and signs a statement that the contract verifies:

claim statement = sign( domain ‖ "claim" ‖ h ‖ buyer )

The claim ends when every crystal has claimed, or after a block height fixed in the contract. After that, anyone may finalize. Finalization keeps

pool atoms = 6,300,000 × sold ÷ 14,698,012

in the contract, sends every other atom it holds to an output that cannot be spent, and opens the pool. Because the pool's atoms scale with the share sold and its BSV is exactly what was paid for that share, the pool opens at the same price whatever share is claimed:

opening price = (14,698,012 × p) ÷ 6,300,000 = 2.333 × p

11.The Pool

After finalization the contract is a constant-product pool. With x satoshis and y atoms in reserve, a purchase paying a satoshis and a sale of s atoms settle as:

buy:   fee = ⌈0.02 a⌉     atoms out = ⌊ y (a − fee) ÷ (x + a − fee) ⌋
sell:  out = ⌊ x s ÷ (y + s) ⌋     fee = ⌈0.02 out⌉     BSV out = out − fee

The fee goes to the treasury in the same transaction. The product x · y never decreases. The contract has no method that pays out its reserves other than these two, so the liquidity cannot be withdrawn by the project or by anyone.

A token output must hold exactly one satoshi, so the contract cannot hold the BSV itself. The BSV sits in a second output, the bank, created beside the contract in each transaction. The bank can be spent only in a transaction that also spends the contract output beside it, so the contract's rules decide every movement of the BSV.

The contract also refuses any transaction that carries outputs other than its own and plain payments of change. Under the BSV-21 rules a transaction that moves more tokens than its inputs hold is invalid and burns all of them [6]; this check prevents a caller from adding outputs that would invalidate the contract's atoms.

12.The Co-signer

A script can verify signatures and arithmetic but cannot read the history of a token. When atoms are sold to the pool, the contract cannot tell real atoms from an output that only claims to hold them, and a sale of false atoms would take real BSV from the pool. The same limit applies to crystals in a claim. For these two facts the contract accepts a statement signed by the co-signer, a Rabin key operated by the project on its server:

• for a claim, that the buyer's address belongs to the holder of the crystal;
• for a sale, that a given output holds exactly the stated number of atoms, as confirmed by the 1Sat BSV-21 index.

The co-signer cannot change a price, an amount, a fee or an output, and cannot move funds. Every statement it signs is published at /api/atoms/attestations. One sale may sell at most 2,000,000 atoms and the co-signer signs at most 30 sales per hour. Its public key is fixed in the contract and listed in the summary above.

If the co-signer's key were stolen, the thief could sign statements for false sales and drain BSV from the pool, within those limits, until the theft was noticed. This is the one place where the $ATOMS contract depends on the project.

13.Fees

BSV is the native coin of the BSV chain, and every transaction pays its network fee in BSV to the miner. At the rate miners currently accept, 100 satoshis per 1,000 bytes, the fees are:

These are paid in addition to the mint price, the royalty and the pool fee.

14.Risks

• The contracts were tested against attacks before deployment. A defect could still exist. A deployed contract cannot be changed.
• The co-signer is a key on a server (§12).
• After the draw, a crystal reaches its owner only when the project's server inscribes it (§6). If the server stops, drawn crystals wait until it runs again; the draw itself is already fixed by the chain.
• Wallets and markets show crystals and atoms by reading indexes of the chain. An index that is down or wrong does not change ownership, but can hide it.
• Nothing in this paper is a promise of price or value. Crystals and atoms may be worth less than was paid for them, or nothing.
• Coins on an exchange are held by the exchange until they are withdrawn. An exchange can fail, delay or refuse a withdrawal.

15.Obtaining BSV

BSV can be bought on exchanges that list it. At the time of writing these include the following, depending on the country:

Withdraw the BSV to a wallet of your own (§16) before minting; Hashstone cannot spend coins held on an exchange. Check the receiving address character by character before withdrawing, and send a small amount first.

16.Wallet

Hashstone works with wallets that implement BRC-100, the BSV wallet interface. Yours Wallet is a non-custodial, open-source browser extension for BSV that holds 1Sat Ordinals and BSV-21 tokens, so it shows crystals and atoms directly. Its source is published under the MIT license.

Install the extension only from the Chrome Web Store link on yours.org. Write down the recovery phrase on paper and store it offline; anyone who has it controls the wallet.

17.Conclusion

We have described a collection whose works are computed from the first blocks of the Bitcoin chain, and a token that distributes the atoms of Bitcoin v0.1 to those works. The inputs are fixed by proof-of-work, the program and the rules are on-chain and committed to by the Seal, and the draw uses a block hash no party knows in advance. The token's claim, burn and pool are enforced by one contract that has no withdrawal method. The project is trusted to create free tickets and to inscribe each drawn crystal; in the token contract its only part, the co-signer, can attest only to holdings, and every attestation it makes is public.

References

1. Bitcoin v0.1, src/market.hSatoshi Nakamoto, 2009. The atoms fields vAtomsIn, vAtomsNew, vAtomsOut.
2. Bitcoin v0.1, src/market.cppSatoshi Nakamoto, 2009.
3. Bitcoin v0.1 releasedSatoshi Nakamoto, cryptography mailing list, 8 January 2009.
4. Bitcoin: A Peer-to-Peer Electronic Cash SystemSatoshi Nakamoto, 2008.
5. 1Sat Ordinals documentationInscriptions, OrdLock listings.
6. BSV-21 fungible tokensDeploy, transfer and burn rules; invalid transfers burn their inputs.
7. Yours WalletOpen-source BSV wallet, MIT license.