Justin Drake

Hashcoin: a new bitcoin where every private key is stored under more than a million hashes

The thing you write down is a seed. The private key is what you get after you hash that seed 1,048,576 times, and you only do it when you mean to spend.

36

Hashcoin trades as HASH.

I will be publishing all findings on GitHub: https://github.com/justindrake. This is my only GitHub. If it is not on that account, it is not from me.

In this newsletter:


A key should be a computation you finish - 2026-10-09

I have been turning the same complaint over for a while. Bitcoin got the money right. A fixed pile of coins, a public ledger, a signature that moves a coin from one address to another, and nobody in the middle who can freeze it because they dislike you. I still think that is the right shape for money. What I do not like is the key.

A Bitcoin private key is a number. Once that number exists as a file, a screenshot, a cloud backup, or a line in a notes app, whoever copies the number can spend. The coin does not know the difference between you and the copy. Most of the sad stories in this space are that story. The key was a thing, and then the thing was in the wrong place.

So here is the idea. Call the chain Hashcoin. It is a new bitcoin. Same coins, same idea of an address, same proof of work, same refusal to invent a new monetary policy because someone got bored. The change is where a private key lives.

It does not live in the wallet. It lives under the wallet. Under a stack of hashes, and the stack has to be longer than a million.

What the stack actually is - 2026-10-09

You start with a seed. A seed is the thing you can write on paper and put in a drawer. Hashcoin defines the private key as what you get after you hash that seed again and again, more than a million times. The number I want as the default is 1,048,576. That is 220. It is just over a million, and it is a power of two, which means a wallet can justify it on one line of code.

h0 = seed
h1 = SHA-256(h0)
h2 = SHA-256(h1)
...
k  = h_1048576          <-- this is the private key
P  = k * G               <-- the public key
address = Hash160(P)     <-- what the chain actually stores

Read that from the top. The seed is the entrance. Each line is a hash of the line above it. The private key is the value at the bottom. Everything between the seed and the key is just hashes, and there are more than a million of them. That is the phrase I mean when I say each private key is stored under over a million hashes. The key is underneath. You reach it by climbing down.

The address is ordinary. Hash the public key, the way Bitcoin already does, and that hash is what appears on the chain. Hashcoin never has to publish k. It never has to publish the seed. It publishes the address, and later a signature that proves someone finished the stack.

The million hashes are your problem, on purpose - 2026-10-09

There is a tempting, wrong version of this. In the wrong version, every node on the network recomputes your million hashes before it will accept a transaction. That sounds thorough. It is a denial-of-service bug with a title. A million hashes per transaction, paid by every verifier, is how you get a chain that falls over the first time someone sends mail.

Verification stays cheap. A node checks a signature against a public key, once, the way it already knows how. The cost sits with the person who holds the seed, and it sits there once, at the moment they decide to spend.

For you, that cost is a blink. A million SHA-256s on a laptop is nothing you will notice. On a phone it is still nothing you will notice. You unlock one wallet. You finish one stack. You sign. You drop k out of memory. The ritual is the point. You meant to be here.

For someone who just copied a hundred thousand wallet files off a backup server, the same rule is a hundred thousand separate climbs. They did not steal a folder of keys. They stole a folder of seeds, and each seed is a job that has to be finished before a single coin moves. Bitcoin already made it expensive to rewrite history. I want it to be expensive to turn a stolen disk into spendable keys.

Checkpoints, and the one rule that matters - 2026-10-09

You should not have to start from the seed every time you want to look at a balance. Looking is free. The address is public. A wallet can also keep a checkpoint partway down the stack, say the hash at step 500,000, so unlocking finishes the rest instead of starting over. Checkpoints are a convenience. They are still hashes. They are not the key.

What you may keepWhat it is
The seedThe entrance. Paper, metal, a drawer. Useless until the stack is finished.
A checkpoint, h_500000A hash partway down. Speeds up the next unlock. Still not a key.
The addressPublic. The chain already has it. Fine to store anywhere.
The private key kForbidden on disk. If you wrote it down, you climbed out, and the million hashes were wasted.

That last row is the whole design. The moment k is a file, you are holding an ordinary bitcoin key again, and Hashcoin has nothing left to say about you. I would treat a wallet that writes the private key to disk as a failed wallet, even if the coins are still sitting there. The depth is the product. Lose the depth and you have lost the only idea.

You can go deeper. You cannot go shallower. - 2026-10-09

A million hashes is a floor, not a personality. I want the depth baked into the address, not hidden in a setting an attacker can turn down after they have your files. A descriptor would look like this:

hashcoin(seed, n=1048576)

n has to be greater than one million or the address is not a Hashcoin address. A careful person, or a wallet holding more than they can shrug off, sets n higher. Ten million. A hundred million. Their choice, committed in public, so a restored backup cannot quietly pretend the stack was short. The protocol’s only opinion is the floor. Under a million, it refuses. Over a million, it is your time and your electricity.

I would also keep a passphrase in front of the seed. The hashes are a speed bump. The passphrase is a lock. They do different jobs, and I want both. A seed alone, hashed a million times, still spends if the attacker is willing to wait. A seed they do not fully have does not.

What this will not do - 2026-10-09

I want to be dull about the limit, because this is where ideas like mine usually get romantic.

If an attacker has your seed and your passphrase, they can compute the same stack you can. The hashes do not add a second factor. They add time, heat, and a reason for bulk theft to be annoying. A person who wants your coins, and who already has the paper from your drawer, will pay the cost and win. I am not selling a new kind of safety against a dedicated thief. I am selling a bad afternoon to the malware that expected a key it could import tonight.

It also does not make a seed easier to remember, and it does not change what a coin is. Supply, halving, proof of work, a signature that either checks or it does not. If Hashcoin needs a paragraph to explain its monetary policy, I have already messed it up. The paragraph is about keys.

One more limit, so nobody writes me a clever follow-up as if I missed it. Finishing the stack on a machine you do not trust is the same mistake as typing a Bitcoin key into a machine you do not trust. The hashes do not bless the computer. They delay the key. Do the work on a machine you are willing to be alone with, sign, and let k disappear.

Why I would actually build it - 2026-10-09

Almost every “new bitcoin” I read wants a faster block or a smarter contract. The failure I keep seeing is older than that. People lose coins because a key was a file, and files move. I would like the key to be a computation you finish on purpose.

If I were shipping the first wallet, the rules on the box would be four lines.

  1. The private key is h_n for n over 1,000,000. It is never the seed.
  2. The depth is part of the address. You can raise it. You cannot drop it under a million.
  3. Nodes verify a signature. They do not re-hash your stack.
  4. A wallet that writes k to disk has failed, even if the balance still shows.

That is Hashcoin. A bitcoin whose private keys are stored under the hashes, and stay there until you decide they should not.


Links

Notes

TIL: 220 is 1,048,576. Just over a million, which is the smallest round number I am willing to call a stack.

Quote: “The private key is not a thing you have. It is a thing you finish.” I wrote that on a scrap and then realized it was the whole post.

ShareRestack

Ready for more?

Subscribe for free to receive new posts and support my work.

36 comments

MK
mina_keys 4h

A million SHA-256s is cheap enough that a small GPU still walks a stolen seed in well under a second. Are you sure the floor is doing any work?

Justin Drake 3h

Against one seed, no, and I said so in the post. The floor is there so a backup of many wallets is a pile of jobs, and so a wallet cannot quietly set the depth to 1,000 and still call itself Hashcoin. If the coins matter, raise n. The protocol’s job is to refuse anything under a million. Your job is to decide how far over.

AL
address_line 3h

Putting n in the descriptor is the part I like. Iteration counts hidden in a config file are how these schemes die. Once the depth is public, a restored file cannot bargain it down.

JH
checkpoint_jim 2h

Storing h_500000 feels like cheating until you remember it still is not k. I would want the wallet to refuse to serialize the last step at all, even into a crash dump.

RP
relay_pete 51m

Glad the nodes are not the ones eating the million hashes. I have watched “the chain should do more work per tx” ideas take out testnets. Signature check stays a signature check. The stack is a custody rule. That split is the idea.