5. Soft fork was implemented to maintain backward compatibility, and below is simple explanation of how miners/nodes validate the new PQC transactions:
A. Old Nodes (not PQC):
1. Only see and validate the classical ECDSA signature
2. Ignore the additional PQC data (they treat it as anyone-can-spend)
3. Continue working as normal
B. New Nodes (PQC):
1. First validate the classical ECDSA signature
2. Then validate the PQC signature
3. Transaction is only valid if BOTH signatures are valid
4. Reject if either signature fails
C. Miners:
1. Old miners: Mine transactions based only on ECDSA
2. New miners: Mine transactions only if both ECDSA and PQC signatures are valid
This creates a soft fork where new rules are stricter than old rules. This dual-signature approach ensures backward compatibility while gradually transitioning the network to quantum resistance. This dual-signature approach ensures backward compatibility while gradually transitioning the network to quantum resistance.
I don't like this approach. With small block size limit (1 vMB or 4 million weight units), it would drastically reduce Bitcoin TPS (transaction per second). I prefer SegWit approach where it's activated some time after 95%+ recent blocks signal SegWit support, where old nodes only see anyone-can-spend TX.
And looking at
https://github.com/QBlockQ/pqc-bitcoin/blob/main/doc/pqc.md, there's no mention it would use Bech32m address with witness version 2 (a.k.a. address with bc1z prefix).