The ever-vigilant @0xbitcoiner posted about this quantum proposal for Bitcoin back in June (#1502579), but I am only now getting around to looking at it.

It seems that it was probably created by someone using a bot (check out @Murch's replies on delving) . While this doesn't mean it shouldn't be discussed, it does seem like a pretty big strike against the idea. Also @conduition replied on the Bitcoin Mailing List that it was "strictly worse than BIP360."

Nonetheless, I found it interesting to think about because it helps me understand how some of these things work.

This proposal suggests using something called Winternitz One-Time Signatures(WOTS). These are hash-based signatures which means they are not vulnerable to Shor's algorithm and are therefore much more resistant to cracking by quantum computers.

The problem with these signatures, as the name implies, is that they can only be used once. So if you generated an address with with this sort of signature in the locking script and somebody sent you coins to the address in two separate transactions, you would only be able to safely spend one of the payments you received, because signing a second transaction would leak your private key.

So, while WOTS is relatively light weight and is quantum resistant, it has this rather huge caveat that a signature can only be used once.

The proposal suggests a Merkle tree construction to solve this problem:

Instead of committing to a single WOTS key pair, a P2WOTS address commits to a Merkle root over 64 independent WOTS public keys, called slot keys. The root is the only value that appears in the scriptPubKey. An observer receiving the address sees a 32-byte hash commitment; they cannot see any of the 64 underlying slot public keys, let alone the secret keys.

When the wallet owner wants to spend a P2WOTS UTXO, they choose one unused slot key from the set of 64 and produce a WOTS+ signature under that slot's secret key. They include in the witness: the 34-element WOTS+ signature, the slot nonce (the domain separator that binds the signature to that specific slot), the 1-byte slot index, and a 6-node Merkle authentication path that proves the chosen slot's public key is a member of the committed set. The verifier independently reconstructs the slot's WOTS+ public key from the signature, then verifies the Merkle path against the merkle_root in the scriptPubKey.

Each slot key is derived deterministically from the wallet's master secret (mskWOTS) and two counters: address_index (which address is being constructed) and slot_index (which of the 64 slots within that address). Every slot key is cryptographically independent; knowledge of one slot's secret key reveals nothing about any other slot. This construction is structurally the leaf layer of RFC 8391 XMSS (eXtended Merkle Signature Scheme), adapted for Bitcoin's UTXO model.

It goes on to claim that it supports RBF, but I don't think this is true. I think the only safe way to use this signature scheme to fee-bump would be Child Pays For Parent, where you use a transaction with a new UTXO to make your previous transaction more attractive. But honestly, I'm not even sure that would work.

The other thing the proposal claims is that you can create 2 of 2 multisigs for Lightning using this sort of signature. Perhaps I missed it, but I think that this is not true: my understanding of lightning is that channel peers share unbroadcasted signed transactions of the multisig state with each other. Presumably, if you had a WOTS-type signature multisig and you shared more than one presigned transaction, you would be exposing your private key.

Whoever this opus lux person is, they enjoy working with LLMs, because they produced a slick-looking website and demo wallet. Also they seem to have tried to create implementations for every chain under the sun.

Oh, and while I was working on this their website went down.