From: Jameson Lopp <jameson.lopp@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 07:38:45 -0400 [thread overview]
Message-ID: <CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG+mg@mail.gmail.com> (raw)
In-Reply-To: <c3b9617f-b419-4fc0-9a00-5d1866f80920n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 6159 bytes --]
I think this could benefit from a lot more blockchain analysis in order to
support the claim that it will reduce economic volatility. On its surface
it feels like a half measure.
Sure, requiring P2PK output spends to be spread out over a year /could/
slow down the /tail end/ of said economic volatility. This is assuming that
post-QDay, the machines doing the cracking can crack a key in less than 10
minutes.
However, a rational quantum adversary will seek to maximize their revenue.
For example, the most valuable likely lost funds
are 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has 31,000 BTC spread across
only a handful of UTXOs. It's not a P2PK address, but a P2PKH with an
exposed pubkey due to address re-use. Even if this proposal is implemented
we can still expect massive economic volatility at the front-end of the
quantum era. Even if this proposal was extended to INCLUDE spends from
re-used addresses, that would be 31,000 BTC in an hour or two.
Moving on to P2PK specifically, I'd expect a similar issue of front-loaded
volatility once a quantum adversary runs through the high value reused
addresses that haven't migrated to a quantum safe scheme. Take, for
example, James Howells' funds at 198aMn6ZYAczwrE5NvNTUMyJ5qkfy4g3Hi - 8,000
BTC spread out across just 16 UTXOs, which would be spendable in a 3 hour
timeframe in this proposal.
On Tue, Apr 29, 2025 at 11:26 PM Michael Tidwell <michael@tidwell•io> wrote:
> I'm much more in favor of this approach vs freezing/burning the coins.
>
> Putting out some thoughts with the assumption this will one day be
> possible*
>
> At least at a high level this has some interesting merits that should be
> considered. Distribution of p2pk coins have pre-determined throttle rules
> that don't lead to any clear bias. Like the BIP explains, deciding which
> coins should be locked is a dangerous precedent. I'm more in favor of
> cryptographic romanticism vs authoritarian UTXO adjudicating. Early p2pk
> were not created with the idea that could be stolen. However imo, it is a
> better in everyway: technical, cultural, moral to allow early, inactive
> vulnerable coins to be naturally recycled without changing the unlocking
> script.
>
> From my search, there's roughly ~45,700 P2PK outputs. I don't think the
> address count matters here. We're looking at nearly one year's worth of
> UTXOs (~317 days), assuming a scenario where, once a key is cracked, there
> will be roughly one cracked key per block thereafter.
>
> Here are a few hypothetical scenarios to consider of many regarding mining
> pools and QC sig producing entities:
>
> - 1. Sigs become public:
> QC sigs become easy to produce and commoditized, freely available for
> every miner to pull from. Mining pools can arbitrarily select the most
> profitable signatures for their blocks. Given the relatively shortish time
> window between becoming available and being commoditized, I think this is
> unlikely.
>
> - 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.
>
> - 3. Bidding war from multiple QC'ers:
> QC sigs produced by multiple entities, leading to potential bidding wars
> as suggested by BIP scenario. However, if the entities controlling the
> signatures are few, collusion to keep fees low and maximize profits
> elsewhere imo is likely to occur. This scenario would somewhat
> counterbalance scenario (2) above.
>
> - 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.
>
> I've discussed this idea off-band and heard concerns regarding MEV
> specifically, (i.e. miners needing QC partnerships or capabilities to
> remain competitive.)
> Considering the approximately 1 year exploit window, and an unknown amount
> of time in the future when this would occur, it's not clear that there
> would be significant MEV concerns during or afterwards for the (post QC
> phase). I consider 1 year in Bitcoin to be a relatively short time period
> that could be stomached as a "phase". Due to potential market panic and
> pressure from QC stakeholders, it's unlikely an entity would choose a
> long-term approach (e.g., 3-4+ years) to exploit these transactions.
> Instead, they'd likely pay fees promptly to outpace other people about to
> make breakthroughs in QC.
> On Tuesday, April 29, 2025 at 7:08:16 PM UTC-4 Hunter Beast wrote:
>
>> This is a proposal to mitigate against potential mass liquidation of P2PK
>> funds. The specification is pretty simple, but the motivation and
>> justification for it is a bit longer.
>>
>> https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki
>>
>> Feedback welcome!
>>
> --
> 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/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegroups.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/CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG%2Bmg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7574 bytes --]
next prev parent reply other threads:[~2025-05-01 15:56 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 [this message]
2025-05-01 17:38 ` Nagaev Boris
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=CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG+mg@mail.gmail.com \
--to=jameson.lopp@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