Rendered at 20:51:20 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
socketcluster 6 hours 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.
Retr0id 13 hours ago [-]
> 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.
> 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
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.
> 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.
> 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