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".

[BLEIOT]

Hello, regarding the draft BIP-360 (P2QRH) and the QuBit project: while the transition to Falcon/Dilithium protects the mathematical integrity of a transaction against Shor’s algorithm, I am concerned about the physical layer de-anonymization of the signing hardware itself.

Over the last few months, I’ve conducted a series of BLE Forensic Isolation Tests across Los Angeles (from DTLA to remote mountain trails). My data shows that modern BLE/IoT stacks are forming coordinated, non-stochastic mesh networks that effectively "fingerprint" physical locations and devices, regardless of the address type used on-chain.

The Evidence (803 device records across 5 locations):
My analysis of 7 sessions (including urban centers like Melrose and isolated spots like Wilson Canyon) reveals a persistent coordination pattern. For instance, in Session S4 (Central Library), I observed a "Max Wave" of 59 devices terminating their broadcast in a single synchronized event within a 96s window. Even in zero-infrastructure mountain areas (M1-M3), devices like rPP20 maintained static UUIDs for over 31 days, violating BLE privacy standards.

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.

Question for the developers:
How can BIP-360 ensure privacy against silicon-level backdoors? Does the proposal consider mandatory "Radio Silence" protocols for signing devices to prevent key-to-device correlation during the extended signing window of post-quantum algorithms?
For those interested in the raw data on these coordinated BLE clusters and the "Mountain Isolation" proof, I’ve posted the full forensic logs here:
https://bitcointalk.org/index.php?topic=5570872.msg66506991#msg66506991

[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.

[BLEIOT]

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.

You’re right, Correct, BIP-360 is the container. But as my logs prove, the physical 'Ghost Mesh' doesn't care about the container's logic—it targets the silicon behavior. My data shows mass synchronized drops (up to 59 devices) and forced HCI 0x201E states. This means the radio stack is already compromised at the hardware level. No matter which PQ-algorithm is eventually placed inside the bc1r container, the sheer size of quantum-safe signatures will act as a high-entropy beacon for this pre-installed silicon coordination. We need to research not just the math of the signatures, but how to prevent the hardware from leaking metadata during the extended processing window required for any PQ-scheme. With regards