From: Nagaev Boris <bnagaev@gmail•com>
To: Michael Tidwell <michael@tidwell•io>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Introducing Hourglass
Date: Thu, 1 May 2025 14:38:08 -0300 [thread overview]
Message-ID: <CAFC_Vt6c_DwmpCzNVCRWzz9E2AGn0PpkZzLeYeGNE1tYbUzyOA@mail.gmail.com> (raw)
In-Reply-To: <c3b9617f-b419-4fc0-9a00-5d1866f80920n@googlegroups.com>
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.
prev parent reply other threads:[~2025-05-01 18:07 UTC|newest]
Thread overview: 4+ 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 [this message]
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=CAFC_Vt6c_DwmpCzNVCRWzz9E2AGn0PpkZzLeYeGNE1tYbUzyOA@mail.gmail.com \
--to=bnagaev@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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