Hey matt (npub185h…wrdp), I can't reply on google groups but you should check out my article on hash-based signatures and my DASK proposal, it's very similar to your idea, in the way clients can opt into future quantum resistance without any consensus changes.
https://conduition.io/cryptography/quantum-hbs/#Upgrading-Bitcoin
I chose a different mechanism for my approach. Instead of an opcode in a tapscript leaf, DASK uses a PQ signature scheme pubkey as an secp256k1 secret key, and assumes future PQ bitcoin clients will validate against that PQ pubkey.
I think your proposal has a major benefit over mine in that it makes soft-fork compliance way easier. My DASK idea seems like it would need a hard fork on Q-Day, but yours would seem to be fully compatible with old clients. Big props 🎉
One idea from my post which I think you might want to consider copying is: Instead of committing to a SPHINCS key on-chain, commit to a hash-based certification key with shorter signatures, like WOTS.
Yes, it's a one-time signature scheme so we can't reuse the key, but we can be pretty sure than post-quantum cryptography will progress a long way in the coming decades, and we can use that one-time signature (which we are highly confident is secure today) to endorse a post-quantum key for a signature algorithm that might not exist yet, or that might exist today but that we don't know is secure, like Kyber.
Your opcode soft-fork would have to specify the exact validation semantics later, but the WOTS authentication key has already been committed to, so the coins are safe.
conduition
npub1l6…6zvtg
2024-12-16 03:02:15
in reply to nevent1q…pc79
Author Public Key
npub1l6uy9chxyn943cmylrmukd3uqdq8h623nt2gxfh4rruhdv64zpvsx6zvtgPublished at
2024-12-16 03:02:15Event JSON
{
"id": "172b5954551079a9050262e99d539b14eb3e581ee2b4cdccb6856c3c8b4a4503",
"pubkey": "feb842e2e624cb58e364f8f7cb363c03407be9519ad48326f518f976b3551059",
"created_at": 1734318135,
"kind": 1,
"tags": [
[
"p",
"3d2e51508699f98f0f2bdbe7a45b673c687fe6420f466dc296d90b908d51d594",
"",
"mention"
],
[
"e",
"798590f9df5b3c0316193c3504692234f148b22bcd59331681331f52481c3b11",
"",
"root"
]
],
"content": "Hey nostr:npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp, I can't reply on google groups but you should check out my article on hash-based signatures and my DASK proposal, it's very similar to your idea, in the way clients can opt into future quantum resistance without any consensus changes. \n\nhttps://conduition.io/cryptography/quantum-hbs/#Upgrading-Bitcoin\n\nI chose a different mechanism for my approach. Instead of an opcode in a tapscript leaf, DASK uses a PQ signature scheme pubkey as an secp256k1 secret key, and assumes future PQ bitcoin clients will validate against that PQ pubkey.\n\nI think your proposal has a major benefit over mine in that it makes soft-fork compliance way easier. My DASK idea seems like it would need a hard fork on Q-Day, but yours would seem to be fully compatible with old clients. Big props 🎉 \n\nOne idea from my post which I think you might want to consider copying is: Instead of committing to a SPHINCS key on-chain, commit to a hash-based certification key with shorter signatures, like WOTS.\n\nYes, it's a one-time signature scheme so we can't reuse the key, but we can be pretty sure than post-quantum cryptography will progress a long way in the coming decades, and we can use that one-time signature (which we are highly confident is secure today) to endorse a post-quantum key for a signature algorithm that might not exist yet, or that might exist today but that we don't know is secure, like Kyber. \n\nYour opcode soft-fork would have to specify the exact validation semantics later, but the WOTS authentication key has already been committed to, so the coins are safe.",
"sig": "3dc11ff8320195368967d86dfc12eaaa1b5469f3d5f81120395f10954c3e443c5f4cb3f7b6f3afc58f0163bfaba3e5e8cdf5f3f45395c09ea54091bddab087d6"
}