> coins that don’t make the jump are effectively burned or otherwise invalidated by consensus, so there’s nothing left for an attacker to sign
If you require the classical ECDSA signature, and a quantum-resistant one, then it will make coins "trapped", instead of "burned". And I think it is better, because then, if some quantum-resistant algorithm will be broken for any reason (some of them were broken classically), then it will be possible to go back to ECDSA, and soft-fork-out of the upgraded version by doing a downgrade, and switching to a different quantum-resistant scheme.
Also, as long as ECDSA is not fully broken, the implementation of all of that will still be needed, to validate all historical blocks.
And of course in some cases, it may be still possible to prove, that you are the original owner of the coin, for example if some key is a part of some HD wallet. By making funds unspendable, instead of trapped, you break all ways of accepting such proofs in the future.
Hi everyone,
Boris’ point about a quantum capable attacker simply broadcasting and self mining at the same time is exactly the scenario that pushed me toward the QRAMP idea in the first place. Rather than trying to chase a well funded adversary around the mempool, QRAMP proposal says: let’s set a firm deadline and make every unspent P2PK output move to a quantum safe address before it arrives. Once the block height or a date passes, anything that stayed behind just stops being spendable. Holders who migrate on time keep full control; coins that don’t make the jump are effectively burned or otherwise invalidated by consensus, so there’s nothing left for an attacker to sign.
Regards,
Agustín
On Wed, Apr 30, 2025 at 12:26 AM Michael Tidwell <michael@tidwell.io> wrote:
> - 2. Single Entity rush spends:
> A single entity generates QC signatures and tries to rapidly flip the UTXOs while having their first mover competitive edge. They either broadcast to the mempool, partner with miners, or mine directly. This creates potential miner collusion if P2PK fees remain low, pressuring the QC entity to raise fees and incentivize miners before their competitive advantage expires and others catch up.
>
[...]
>
> - 4. Patient Miner:
> A single QC capable entity, also operating as a miner or partners with a miner, chooses to be patient, including P2PK transactions only in their own blocks to maximize long-term profits.
IMHO for a single QC capable entity even if it mines itself or
partners with a miner, it would make sense to broadcast the
transaction publicly. If it doesn't broadcast, then it can only
capture one UTXO when it mines a block - rarely, depending on their
hashrate share. If it mines itself and broadcasts at the same time,
there is a possibility that another miner includes the transaction
into a block. So a rational QC capable entity would broadcast in
addition to mine themselves.
Also it would make sense to use different UTXOs for broadcasting and
for self mining: if another miner mines one UTXO, the QC entity can
continue mining another UTXO trying to mine the next block with it. If
they use the same UTXO, they would have to quickly make a signature
for a fresh UTXO for their own block. Or just have a pool of attacked
UTXOs and take them one by one...
--
Best regards,
Boris Nagaev
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAFC_Vt6c_DwmpCzNVCRWzz9E2AGn0PpkZzLeYeGNE1tYbUzyOA%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJDmzYyAb4GT%2BrdpF8ndAcFrFziQyO%3DQpA36m1T8gw0LTLLg-g%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOKXtmN7dwCX63UBhc4GhMAUOuaYKMfyj4Aa8-qv3v8c_Q%40mail.gmail.com.