Apparently, the people have grown bored with BIP 110 and with MSTR and even AI is feeling a little insipid (it's been a few days since everybody got worked up about something), so I guess we're having a quantum moment.

NVK gets a little sloppyNVK gets a little sloppy

NVK came out with this long piece on X about quantum computing and Bitcoin. It's really long. It's definitely llm, but I saw a lot of good details when I skimmed it. You could probably do a lot worse if you were looking for a single place to get up to speed on quantum stuff and Bitcoin.

Here's a nice distillation:

So What Should You Actually Do?So What Should You Actually Do?

If you're a Bitcoin holder:

1. Don't panic. The threat is real but distant. You have time.
2. Stop reusing addresses. Every time you reuse an address, you expose your public key. Use fresh addresses for every receive.
3. Watch for BIP-360. When quantum-resistant address types become available, migrate your funds.
4. If you're holding long-term, consider keeping funds in addresses you've never spent from. Your public key stays hidden.
5. Ignore the headlines. Read the actual papers. They're more interesting and less scary than the coverage suggests.

If you're a Bitcoin developer:

1. BIP-360 needs more reviewers. The testnet is running. The code needs eyeballs.
2. The 7-year timeline needs to compress. Every year of delay narrows the safety margin.
3. Start the governance conversation about legacy UTXOs. Satoshi's coins won't protect themselves. The community needs a plan.

If you're someone who just read a scary headline:

Remember that 59% of shared links are never clicked. The headline is designed to make you feel something. > The paper underneath is designed to make you think something. Go read the paper.

UDI doles out the FUDUDI doles out the FUD

About an hour before NVK published his more reasonable take, the ever-sensational Udi Wertheimer published a scream sheet piece about how quantum computing is going to kill lightning:

Unfortunately, public keys on the lightning network (the bitcoin payment network adopted by coinbase, binance, square/cashapp, and others) are not secret.

you see, for lightning to work, every wallet manages what’s called a “payment channel” with some counterparty. this often happens transparently without the user knowing. behind the scenes the wallet creates private and public keys, contacts a counterparty (usually some service provider) and exchanges public keys with them. the entire user balance is then deposited in this “channel”.

the channel is just a multisig address on the base layer. for multisig to work (even if it’s using next-gen schemes like musig or FROST), all participants in the channel have to know everyone else’s public keys.

this is considered ok, because those keys are meant to be public. lightning has some other tricks up its sleeve to ensure that your private key is required if anyone wants your lightning balance. the service provider can’t just take your funds.

but remember, powerful enough quantum computers can calculate your private key from the public key.

so if you’re using lightning, your service provider has your public key. you might not even know who it is. and if they ever get access to a CRQC, or leak their data to someone who does, all your coins can be stolen.

oh, and all they need is a slow quantum computer btw. they don’t need the hypothetical fast kind that google was talking about, that could crack keys in 9 minutes.

Udi seems to think he's found a big gotcha here, but I think he's missing something: every lightning channel is really a two of two multisig. So, it's not like everyone can see all the pubkeys for every lightning channel. Because of how lightning channel locking scripts are constructed, their pubkey isn't revealed until the channel is closed (I am ninety percent sure on this, but hopefully I'll get a doublecheck from someone who knows for sure).

So, what Udi's really fudding here is that your channel partner will have a quantum computer and be able to crack your private key from the funding transaction pubkey from when you created the channel. He kind of acknowledges this by having a section entitled "but my lightning service provider doesn’t have a quantum computer"

This is Udi being ridiculous. This sort of fear-mongering about quantum is absurd. Lightning is not broken because of quantum.

Giacomo Zucco speaks common senseGiacomo Zucco speaks common sense

Finally, Giacomo Zucco posted a reply to a conversation on X with this rather nice summary of his attitude towards quantum threats to Bitcoin:

Part of the disagreement is, of course, about probability estimations of such an attack in general (physics-illiterate normies tend to overestimate it, physicists working on related products willingly tend to overrepresent it). But another part seems to come from a misunderstanding abut "how to protect your long-term savings from it if you want, as a hodler, assuming the attack ever materializes".

Some seem to think a consensus change is needed now for that, but that's not the case: you can just use hash-locked outputs instead of "naked" public keys. Today. Now. Without any change to Bitcoin. If the attack was on-the-fly, you would need to wait for a soft fork including a commit&reveal scheme before spending. If it was just at-rest, you'd just need wait for one with a new signature scheme (lattice or hash or whatever). The rest is just nonsense central planning hysteria about confiscating "vulnerable" coins that other people won't or can't move (idiotic nonsense).

A more subtle variant of this misunderstanding is expressed with the idea that you can only do that with old p2pkh addresses and similar legacy script types, but not with taproot.

But that's not true either, afaik. A taproot output accepts any 32 byte string, even if it's not a valid point on secp256k1 satisfying (y^2=x3+7)mod(p): about half are not. But I'm quite sure you can still commit to Q=P+H(P∥m)⋅G, for every m you want in term of tapscript root, even if the P is "fake" (not a residue).

If this is correct, as I assume it is (maybe somebody more familiar with tapscript can correct me if not), it's trivial to use taproot too in a "quantum safe" 😂😂 way. Even now, without any soft fork. And just wait for a future consensus change (with or without commit&reveal scheme, based on the attack speed) before spending.

Still: I'm happy with my key spending happy-path, and I'm not going to do that, until I see a reproducible quantum computer with error rate and coherent size close to the danger zone by a couple magnitude order (I suspect that will never happen due to physical constraints).

Giacomo's approach seems pretty reasonable to me.

The quantum scare will pass until the next round of fund raising and we will hopefully have a lull between that and when the BIP 110 guys get going again where we can talk about something cool, like covenants.