From: Agustin Cruz <agustin.cruz@gmail•com>
To: Nagaev Boris <bnagaev@gmail•com>
Cc: Michael Tidwell <michael@tidwell•io>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Introducing Hourglass
Date: Thu, 1 May 2025 14:23:21 -0400 [thread overview]
Message-ID: <CAJDmzYyAb4GT+rdpF8ndAcFrFziQyO=QpA36m1T8gw0LTLLg-g@mail.gmail.com> (raw)
In-Reply-To: <CAFC_Vt6c_DwmpCzNVCRWzz9E2AGn0PpkZzLeYeGNE1tYbUzyOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3349 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4303 bytes --]
next prev parent reply other threads:[~2025-05-02 11:06 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 [this message]
2025-05-02 13:58 ` Saint Wenhao
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='CAJDmzYyAb4GT+rdpF8ndAcFrFziQyO=QpA36m1T8gw0LTLLg-g@mail.gmail.com' \
--to=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