<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div dir="auto">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.<br></div><div dir="auto"><br></div><div dir="auto">The rest of the chain is ordinary Proof of work unspent output model, Merkle trees, difficulty retargeting every 2016 blocks. <br></div><div dir="auto">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.<br></div><div dir="auto">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. <br></div><div dir="auto">Heavy system requirements would mean that hardware capable of running it stops being affordable for most people. <br></div><div dir="auto">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.<br></div><div dir="auto"><br></div><div dir="auto">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. <br></div><div dir="auto">Then that file is cut into slices called leaves and the chain stores nothing but the Merkle root of that file. <br></div><div dir="auto">To spend an input must be revealed one leaf together with a proof binding it to that exact transaction. <br></div><div dir="auto">Such a leaf is never used again and the signature on its own cannot authorise anything.<br></div><div dir="auto">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.<br></div><div dir="auto">Private users and institutions alike can build their own modules collecting entropy from sources such as sandstorms, radar data or anything else. <br></div><div dir="auto">That could create a market for external devices supplying entropy and everyone could pick a source that they like it most. <br></div><div dir="auto"><br></div><div dir="auto">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. <br></div><div dir="auto">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. <br></div><div dir="auto">In such a construction the whole history would live only on government or corporate servers because only they can afford that.<br></div><div dir="auto">With small blocks there was a risk that nodes would be busy with confirmations alone and users would not get new transactions through.<br></div><div dir="auto">WOTS is a good solution just not in this place so I simplified it down to an entropy file cut into leaves.<br></div><div dir="auto"><br></div><div dir="auto">My approach was inspired by the fragments I found about Russian stream communication systems from soviet union era.<br></div><div dir="auto">I know this might be controversial but their approach back then was based on simplicity and effectiveness.<br></div><div dir="auto"> Theirs always rested on the greatest possible simplicity and that convinced me. <br></div><div dir="auto">By the way I am not a professional cryptographer so I spent two years on successive versions of this.<br></div><div dir="auto">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. </div><div dir="auto">I really want to point out here that this is not a one-time pad and I do not claim it is. <br></div><div dir="auto">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. <br></div><div dir="auto">Such a material is used for authorisation rather than encryption and it is bound to a commitment published on the chain.<br></div><div dir="auto"><br></div><div dir="auto">There is one scenario I worry about. <br></div><div dir="auto">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.<br></div><div dir="auto">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.<br></div><div dir="auto">The same question applies to WOTS.<br></div><div dir="auto">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.<br></div><div dir="auto"><br></div><div dir="auto">Questions I cannot answer myself is:</div><div dir="auto">Does this construction have a name? <br></div><div dir="auto">It feels close to a commitment to a set of one-time authenticators but I have not found it described that way.<br></div><div dir="auto">Has anyone analysed its weak points? <br></div><div dir="auto">The obvious ones are not entropy quality because If the entropy is derived from sources with unpredictable behavior it should be high-quality entropy. <br></div><div dir="auto">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. <br></div><div dir="auto">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.<br></div><div dir="auto">As well the implementation refuses to create entropy file when the timing measurements do not vary enough.<br></div><div dir="auto"> On an Android phone under a compatibility layer on UserLand it found six distinct values in 256 samples and refused. <br></div><div dir="auto">I would welcome any opinions on whether host timing noise is a defensible source for something carrying this much weight.<br></div><div dir="auto">The code is public under the MIT licence if anyone wants to look at the construction itself.<br></div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/natusor/MONEU/blob/main/MONEU-White-Paper_EN.md" rel="noopener noreferrer" target="_blank">https://github.com/natusor/MONEU/blob/main/MONEU-White-Paper_EN.md</a><br></div><div dir="auto"><br></div><div dir="auto">natusor<br></div> </body>
</html>