Hi everyone. I would like to start this technical discussion with the topic of protecting Bitcoin from possible future threats
At the moment, one of the first practical approaches to reducing this risk has already been proposed: not revealing the public key until the moment of spending. Quantum resistance for Bitcoin is no longer a distant topic, it is actively discussed at the protocol level. One of the first practical approaches is already on the table: BIP360 / P2QR, where the public key is not placed in the output in advance, but is only revealed during the spend. This reduces the dangerous window to the time between broadcasting the transaction and confirming it in a block. For Bitcoin, that is around 10 minutes on average.
In my opinion, this method is only the first step toward a stronger protection model. Based on developer discussions, it is clear that many people are considering a future move from ECDSA to XMSS signatures for several reasons. First, XMSS is closer to the hash-based signatures model, which fits the Bitcoin philosophy well. It is also a very natural structure for integration and migration. Second, weight: XMSS wins in transaction weight compared to other cryptographic schemes, for example Dilithium. Third, the one-time / few-time signature limitation can be partially adapted to the UTXO model. Bitcoin wallets have long used change outputs, meaning that after a spend, the change goes to a new output / new address. This allows a model where funds move to new key material after each spend. Bitcoin already has this function when change is returned to a new change output / new address.
The other side of the discussion is Falcon, Dilithium and other NIST PQC signatures. The core problem is straightforward, signature sizes are large. With blocks of only a few megabytes, only a few hundred heavy transactions may fit into a block. For Bitcoin, where thousands of transactions per block are expected under normal conditions, this creates real pressure: higher fees, a bloated mempool and long confirmation times.
Among these schemes, Dilithium stands out as a reasonable candidate despite its size. It is NIST-standardized, well-analyzed, and has a relatively predictable security model. The size argument is real, but I think it is an engineering problem, not a reason to reject the scheme outright. So instead of dismissing Dilithium, I decided to test whether changing how this data is stored and accounted for could make it viable.
I prepared a working technical example of PQ Witness for Dilithium.
Dilithium signature data is moved from legacy scriptSig into the witness part of the transaction.
A separate weight accounting model is introduced for PQ witness.
Legacy outputs remain valid, and migration is not forced.
PQ sigops are counted separately, so the network understands the real cost of verifying post-quantum signatures.
Mempool, block validation, wallet/RPC and transaction weight/vsize paths are updated for the new model.
This approach uses a witness accounting factor K = 16. The value is based on the SegWit witness discount ratio scaled up to reflect the verification cost of Dilithium relative to ECDSA, roughly 4x compute overhead on top of the size difference. It is a starting point, not a final value. A heavy Dilithium signature is accounted for much more efficiently in the block than with the direct legacy approach. In my tests, this gives roughly a 12.7x improvement in effective block usage for PQ signature data. If the legacy model can fit roughly 50 heavy PQ transactions into a block, then after PQ Witness activation the capacity can be around 600-700 PQ transactions per block. With proper integration and math, the coefficient could potentially be increased to 32/64 and bring capacity to around 2,500-3,000 transactions per 10 minutes. The exact numbers depend on the structure of specific transactions: the number of inputs, outputs, witness data and selected block parameters. But the order of improvement shows that Dilithium does not necessarily have to be dismissed only because of signature size.
I think that instead of sacrificing the level of cryptographic protection for lower weight, we can try to keep a NIST-standardized signature scheme and adapt the transaction layer to the real size of post-quantum signatures.
XMSS also has a weak point, it is a more fragile model for wallets and users. If a wallet manages indexes incorrectly, reuses a leaf/key, or a user manually builds a transaction carelessly, a situation may happen where part of the funds is sent, while another part remains tied to already revealed key material. This is a separate operational risk. That is why I personally do not consider XMSS to be the only convenient path.
The implementation is available here, check it out and tear it apart. I think it adds one more technical perspective worth having in the discussion.
https://github.com/q-bitx/pq-witness-technical
