From: Saint Wenhao <saintwenhao@gmail•com>
To: Agustin Cruz <agustin.cruz@gmail•com>
Cc: Nagaev Boris <bnagaev@gmail•com>,
Michael Tidwell <michael@tidwell•io>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Introducing Hourglass
Date: Fri, 2 May 2025 15:58:02 +0200 [thread overview]
Message-ID: <CACgYNOKXtmN7dwCX63UBhc4GhMAUOuaYKMfyj4Aa8-qv3v8c_Q@mail.gmail.com> (raw)
In-Reply-To: <CAJDmzYyAb4GT+rdpF8ndAcFrFziQyO=QpA36m1T8gw0LTLLg-g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5094 bytes --]
> 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 <agustin.cruz@gmail•com> 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 <bnagaev@gmail•com> wrote:
>
>> 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
> <https://groups.google.com/d/msgid/bitcoindev/CAJDmzYyAb4GT%2BrdpF8ndAcFrFziQyO%3DQpA36m1T8gw0LTLLg-g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
[-- Attachment #2: Type: text/html, Size: 6409 bytes --]
next prev parent reply other threads:[~2025-05-02 15:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 22:38 [bitcoindev] " Hunter Beast
2025-04-30 3:01 ` [bitcoindev] " Michael Tidwell
2025-05-01 11:38 ` Jameson Lopp
2025-05-01 17:38 ` Nagaev Boris
2025-05-01 18:23 ` Agustin Cruz
2025-05-02 13:58 ` Saint Wenhao [this message]
2025-05-02 15:45 ` Francis Pouliot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACgYNOKXtmN7dwCX63UBhc4GhMAUOuaYKMfyj4Aa8-qv3v8c_Q@mail.gmail.com \
--to=saintwenhao@gmail$(echo .)com \
--cc=agustin.cruz@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail$(echo .)com \
--cc=michael@tidwell$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox