Dilithium and Bitcoin: Enhancing Security without Sacrificing Block Size

2 replies 469 views
Posts: 1 · Reputation: 58
#1Sep 8, 2017, 03:15 PM
Hey folks. I wanna kick off this tech convo about keeping Bitcoin safe from potential future threats. Right now, there's a solid approach on the table to cut down on this risk: holding back the public key until it's time to spend. Quantum resistance isn’t just a future concern anymore; it’s getting real attention at the protocol level. One of the first practical ideas out there is BIP360 / P2QR, which means the public key stays hidden in the output until the transaction is actually spent. This shrinks the risky window to just the time between when you send the transaction and when it gets into a block, which usually takes about 10 minutes. I think this is just the beginning for a more solid protection system. From what the devs are saying, a lot of them are looking at switching from ECDSA to XMSS signatures for a few reasons. First off, XMSS leans more towards hash-based signatures, which fits nicely with Bitcoin's philosophy. It also makes for an easier integration and migration process. Plus, when it comes to size, XMSS is lighter on transactions compared to other crypto schemes, like Dilithium. And the whole one-time/few-time signature deal can be tweaked to fit the UTXO model. Bitcoin wallets have been using change outputs for ages, so after a transaction, that change goes to a new output/new address. This way, funds can shift to fresh key material after each spend, and Bitcoin already does this when change gets sent back.
5 Reply Quote Share
paul.ninjaFull Member
Posts: 152 · Reputation: 539
#2Sep 8, 2017, 05:02 PM
I agree with you on XMSS being a wallet-footgun. Stateful signatures are fine in a lab and terrifying in the hands of humans, backup scripts, half-broken mobile wallets, and "I restored an old seed from 2022, why did my coins evaporate?" type situations. Bitcoin already has enough ways for people to shoot themselves in the leg. Adding "reuse this internal signing state and you may expose yourself" is not exactly Grandma-proof, lol. Dilithium / ML-DSA being stateless is a big practical win, but I would be careful with the "just an engineering problem" framing. In Bitcoin, engineering problems become political problems, then mempool problems, then DoS problems, then ten years of mailing list archaeology. A separate PQ witness bucket makes sense conceptually, but the weight discount has to be brutally honest about validation cost. If the discount is too generous, you didn't solve capacity, you just invented a new spam coupon with a NIST sticker on it. The part I like most is preserving legacy outputs and making migration opt-in instead of trying to boil the ocean. That is how Bitcoin actually moves. Give people a path, make the cost visible, don't break old assumptions, and let paranoid wallets move first.
2 Reply Quote Share
LuckyCoinLegendary
Posts: 832 · Reputation: 4795
#3Sep 8, 2017, 10:06 PM
I have a feeling the privacy community doesn't exactly rush to implement NIST recommendations without first evaluating other options to be reasonably confident about cleanliness from backdoors. E.g. with the P-256 and related curves by NIST, Satoshi chose to use secp256k1 instead even though it's a similar size. Now of course, that's just one person, but I can't help but think there's a lot of other developers who think that way.
2 Reply Quote Share

Related topics