[Cryptography] Spending needs a leaf from a local entropy file. Not just the key

[natusor at tutamail.com]

I have built a proof-of-work chain and ended up with a spend authorisation scheme I cannot place in the literature so I would be grateful for pointing to papers that I should be start reading.

The rest of the chain is ordinary Proof of work unspent output model, Merkle trees, difficulty retargeting every 2016 blocks. 
I put just  together what I found like Lego so the main new part is the shield that protects coins from spending by anyone who does not have a noise file created for the wallet.
I wanted anyone with an ordinary laptop to keep the full history of the chain but SSD prices keep going up and in 2026 drives above two terabytes are still not standard in home computers. 
Heavy system requirements would mean that hardware capable of running it stops being affordable for most people. 
So I built it to run even on old computers because then if it runs on old hardware then it will be run as well  i hope so in future on much better newer ones and I wanted something light that will not clog the network.

So every wallet holds a local file of entropy gathered from physical measurements on the machine that created it from electron movement, semiconductor vibrations, temperature changes. 
Then that file is cut into slices called leaves and the chain stores nothing but the Merkle root of that file. 
To spend an input must be revealed one leaf together with a proof binding it to that exact transaction. 
Such a leaf is never used again and the signature on its own cannot authorise anything.
Good thing is that so any future improvement to entropy collection can be introduced without changing the consensus rules because chain does not check where the noise came from.
Private users and institutions alike can build their own modules collecting entropy from sources such as sandstorms, radar data or anything else. 
That could create a market for external devices supplying entropy and everyone could pick a source that  they like it most. 

About one year ago I built it on WOTS one-time signatures and that worked but the proof sizes were unsustainable and when I tested that version I do not remember exactly but  I think it was around 1750 bytes against 64 bytes for Ed25519 and with a large number of confirmations a wave built up that clogged the blocks. 
To fit it was needed much larger blocks but then an ordinary user cannot keep a full node on their disk and has to prune the history. 
In such a construction the whole history would live only on government or corporate servers because only they can afford that.
With small blocks there was a risk that nodes would be busy with confirmations alone and users would not get new transactions through.
WOTS is a good solution just not in this place so I simplified it down to an entropy file cut into leaves.

My approach was inspired by the fragments I found about Russian stream communication systems from  soviet union era.
I know this might be controversial but their approach back then was based on simplicity and effectiveness.
 Theirs always rested on the greatest possible simplicity and that convinced me. 
By the way I am not a professional cryptographer so I spent two years on successive versions of this.
But If  an attacker who recovers the private key still is not able to moves coins  and that includes an attacker with a quantum computer even though the Ed25519 signatures themselves would not survive Shor then i like it. I really want to point out here that this is not a one-time pad and I do not claim it is. 
The only thing that ties it to the OTP is the creation of the entropy file from sources that cannot produce the same results twice. 
Such a material is used for authorisation rather than encryption and it is bound to a commitment published on the chain.

There is one scenario I worry about. 
If Alice sends a transaction to Bob. Then attacker who has already managed to compute her private key sees that transaction and he copies the leaf out of it and pushes his own transaction with a higher fee using that same leaf.
I assume this does not work because the leaf proof is verified against the hash of the transaction it sits in. The attacker's transaction has different outputs so a different hash and verification should fail and leaf spent once cannot be used again. But that is my assumption not the result of independent analysis or of testing on the live network.
The same question applies to WOTS.
I also do not know how long a quantum computer would need to compute a private key. I assume thirty minutes but that is just a guesswork.

Questions I cannot answer myself is:Does this construction have a name? 
It feels close to a commitment to a set of one-time authenticators but I have not found it described that way.
Has anyone analysed its weak points? 
The obvious ones are not entropy quality because If the entropy is derived from sources with unpredictable behavior it should be high-quality entropy. 
However the only issue I see for now is the risk of the noise file being stolen.  That  risk that can be mitigated by storing the file on external media and using it only when performing a transaction. 
This could enable a multi party authentication system where one person holds the noise file, another has the password for that file, and a third holds the private keys. In this way none of these individuals could transfer the funds on their own.
As well the implementation refuses to create entropy file when the timing measurements do not vary enough.
 On an Android phone under a compatibility layer on UserLand  it found six distinct values in 256 samples and refused. 
I would welcome any opinions on whether host timing noise is a defensible source for something carrying this much weight.
The code is public under the MIT licence if anyone wants to look at the construction itself.

https://github.com/natusor/MONEU/blob/main/MONEU-White-Paper_EN.md

natusor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260914/1c1852b9/attachment.htm>