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).
he SegWit-style PQC implementation has been successfully pushed. Here's what we've accomplished:
1. SegWit Integration:
PQC signatures now stored in witness area
Reduced impact on block size through witness discount
Backward compatibility with old nodes
2. New Address Format:
Added Bech32m support with witness version 2
New bc1z prefix for PQC addresses
Compatible with existing wallet software
3. Validation Updates:
Modified validation logic for witness-based signatures
Implemented proper weight calculations
Maintained hybrid signature approach
it is now addressing both the block size concerns and backward compatibility issues. BTW, we need any comments in Github and we need also Bitcoin Core community consensus.