Is the proposed BIP 360 the correct way to achieve quantum attack resistance?

[stwenhao]

and some P2TR

Not some. All P2TR. If you can spend by key, then you can completely ignore all TapScript behind it. And even if someone used some NUMS point, then still: when secp256k1 will be broken, private keys for these points will be known, too.

The only unaffected P2TR or P2PK are those with invalid public keys, but they cannot be moved by anyone.

[hmbdofficial]

The only unaffected P2TR or P2PK are those with invalid public keys, but they cannot be moved by anyone.

If P2Pk with an invalid public key is accepted into the blockchain and it is not spendable is that not following the Morden consensus? I was thinking it shouldn’t be accepted because of the checksig. because I read that this might only occur due to errors from wallet software or malicious crafting.

[stwenhao]

If you use "020000000000000000000000000000000000000000000000000000000000000004 OP_CHECKSIG", then it is difficult to move, but it is mathematically spendable. But if you use "020000000000000000000000000000000000000000000000000000000000000005 OP_CHECKSIG", then it is unspendable, and will never be moved by anyone.

For Taproot equivalents, bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqzqln7y9h is difficult to move, but potentially spendable. However, bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqzs2jkusy is unspendable.

I was thinking it shouldn’t be accepted because of the checksig.

Scripts are validated, when coins are spent, not when they are created. Also, rejecting invalid public keys would slow down validation.

There are around 0x80000000000000000000000000000000a2a8918ca85bafe22016d0b997e4df60 unspendable public keys in 256-bit range. And a lot of more ways to make unspendable scripts, like "OP_2 OP_2 OP_ADD OP_5 OP_EQUAL".

[ABCbits]

The Problem for BIP-360:
Falcon signatures are significantly larger (~10x-20x) than ECDSA/Schnorr. This requires more processing time and longer radio-silence-breaking transmission windows. If the silicon-level BLE/IoT stacks contain factory-level "debug" backdoors or coordinated termination triggers (as my logs suggest), the moment you sign a "quantum-safe" bc1r transaction, you are potentially broadcasting a unique RF-fingerprint that links your physical identity to your UTXO.

It's clear you never read BIP 360 properly.

While this proposal does not include the introduction of post-quantum signature schemes, we think it's worth commenting on security considerations related to this possibility.

Quantum-resistant signature algorithms (e.g. ML-DSA or SLH-DSA) offer different levels of protection and should be scrutinized before use. We are currently researching options for the potential proposal of post-quantum signatures into Bitcoin and encourage others to engage in this research as well.

We also imagine the possibility of introducing multiple post-quantum signatures for redundancy. Balancing the risks of additional complexity with the benefits of signature-type redundancy will be the challenge here.

BIP 360 doesn't enforce Falcon or other QC resistant cryptography usage.

[hyperminer]

A data point that may be useful here: I maintain a small 2014 scrypt chain (Blazecoin, UTXO, Bitcoin Core 28 based), and in September we deployed a post-quantum output type on mainnet. It's not Bitcoin, and some of our choices only work because the chain is small, but the measured numbers carry over.

What we built: a hash-committed output (32-byte hash of the key blob) spent with an ML-DSA-44 (FIPS 204) signature through a new opcode. It's a single scheme with no ECDSA hybrid, and a versioned algorithm ID so ML-DSA-65/87 or SLH-DSA can be added later without a new address format.

Sizes and speed, measured:

	ECDSA P2PKH	ML-DSA-44
Input size	148 B	3,782 B
Inputs per 1 MB (no witness discount)	~6,700	~264
Inputs per 100 KB standard tx	~670	26
Verify, one core (managed code)	254 µs	132 µs

Verification is not the bottleneck. A full block of ML-DSA-44 inputs verifies in about 35 ms. Bytes are what bind: a 25x cut in inputs per block. On Bitcoin a witness discount would soften that, but it is still the main cost.

Why not SLH-DSA first: SLH-DSA-SHA2-128s has the most conservative assumptions, but signatures are ~7.9 KB and signing took ~835 ms each in our tests (a 12-input transaction took 10 s to sign). We reserved it as the fallback if lattices break. Falcon is smaller but FIPS 206 isn't final, and its floating-point signing is a known implementation hazard.

On P2MR: the hash commitment protects against long exposure, but a script leaf that still ends in a classical signature only moves exposure from "first spend" to "first spend of that leaf". Our chain has no tapscript, so we did the signature scheme first. For Bitcoin, I'd read that as an argument for P2MR and a post-quantum opcode arriving close together.

Consensus cost: a 1,312-byte public key and a 2,420-byte signature can't be pushed under the 520-byte element limit. We relaxed it only for inputs spending the new template, which made it a hard fork for us (our chain has no segwit). In a new tapscript leaf version that would be a soft fork.

What doesn't carry over: the rollout. We picked the activation height with about a day's notice, which is only possible when one operator runs most of the hashrate. And the hard part remains migration: coins on reused or spent-from addresses stay exposed until their owners move them. That's a holder-behaviour problem no output type solves.

I'm happy to share the benchmark details or the signature-digest design if that's useful for this thread.

[zeuner]

It seems though, because he is not a cryptographer, the proposal does not choose 1 signature scheme, but rather gives users the option to choose from many. I think that's a bad idea as expecting users to understand the tradeoffs between different cryptosystems is fundamentally untenable.

The implication does not hold. When giving multiple options in a protocol update, client software could still provide a default which is assumed to be secure. But when the assumption is found to be wrong, it's more convenient to update the default rather than waiting for yet another soft fork with a better signature scheme to be deployed.

[gwestcot]

From what I can tell, Hunter is not a cryptographer, so I take this proposal with a very large grain of salt. It seems though, because he is not a cryptographer, the proposal does not choose 1 signature scheme, but rather gives users the option to choose from many. I think that's a bad idea as expecting users to understand the tradeoffs between different cryptosystems is fundamentally untenable. From a cursory reading, if one of those cryptosystems were broken, user funds could be significantly at risk. This proposal to me seems to be written by someone who strongly cares about quantum security, but is not a cryptographer so went with the classic "we do all these different cryptography things so it must be secure!"

There is some discussion about this in this mailing list thread;https://groups.google.com/g/bitcoindev/c/oQKezDOc4us/m/pIL6rZbtAQAJ including response from a cryptographer and seasoned bitcoin soft fork proposers.

The biggest trade-offs seem to be bytes and/or the ease of verification for PQ signatures.

I heard some wallets already started working on adding bc1z segwit v2 addresses from bip-360 proposal, but thus is still in early development phase.

What I don't understand is how adding new type of addresses is going to give quantum protection to bitcoin, unless all bitcoin is moved from old to new addresses?

I feel like node communication also needs to be quantum-resistant. If only the signatures are resistant, there are still glaring vulnerabilities.