> 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. pt., 2 maj 2025 o 13:06 Agustin Cruz napisał(a): > 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 Thu, May 1, 2025 at 2:07 PM Nagaev Boris wrote: > >> On Wed, Apr 30, 2025 at 12:26 AM Michael Tidwell >> 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.