From One Seed to a Thousand Leaves – Merkle's Authentication Tree
0xkrt26.github.io40 points by denismenace 4 days ago
40 points by denismenace 4 days ago
This article describes exactly the quantum-resistant stateful signature scheme I implemented (from scratch) for my blockchain project about 6 years ago; including the Merkle 1979 variant of Lamport OTS. I also constructed a Merkle Signature Key for multiple-reuse in the exact same way described by the article. See https://capitalisk.com/whitepaper#29-passphrases-and-signatu....
The article stops exactly where I did and doesn't go further into SPHINCS+ which builds on top of the same primitives to provide statelessness.
And the reason I stopped at that was probably the same. There is already a fair amount of complexity involved. I wanted a signature scheme which would be relatively simple to understand and implement. Also, there were no good SPHINCS implementations at the time for my engine/language and I didn't feel confident to implement from scratch.
Also, no project at the time (except I think IOTA) had stateful signatures and I liked the idea of being able to change passphrases as it could potentially allow people to sell their wallets (along with associated DEX memberships or delegate spots) to other people.
At the time, I was forging as a delegate on a different DPoS blockchain and I was thinking that it would be nice if I could sell my wallet (which would have been worth 5x to 10x my annual block earnings)... Unfortunately, I couldn't do that (no mechanism for it) and I ended up losing that income stream, never having the option to cash out.
> Does it mean Merkle’s authentication tree is still used today?
> It is. In fact, the Merkle tree is a fundamental part of blockchain.
True, and merkle trees are just about everywhere, but more interestingly it's part of SLH-DSA (the NIST standardization of SPHINCS+), a quantum-secure signature scheme. And it's not just any old merkle tree, it's a continued evolution of the original Lamport signature scheme discussed in the article.
And maybe soon in even more places :) Merkle Tree Certificates (https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tr...) seems to be in order to "make space" for quantum-secure signatures if I understand it correctly:
> Current signature schemes can use as few as 32 bytes per key and 64 bytes per signature [RFC8032], but post-quantum replacements are much larger. [...] a new form of X.509 certificate that integrates logging with certificate issuance [...] This achieves the following: Log entries do not scale with public key and signature sizes. Entries replace public keys with hashes and do not contain signatures