public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoindev] Introducing Hourglass
@ 2025-04-29 22:38 Hunter Beast
  2025-04-30  3:01 ` [bitcoindev] " Michael Tidwell
  0 siblings, 1 reply; 2+ messages in thread
From: Hunter Beast @ 2025-04-29 22:38 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 653 bytes --]

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/db3d0ec4-90b8-44a4-b912-b98ec9083b10n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1273 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [bitcoindev] Re: Introducing Hourglass
  2025-04-29 22:38 [bitcoindev] Introducing Hourglass Hunter Beast
@ 2025-04-30  3:01 ` Michael Tidwell
  0 siblings, 0 replies; 2+ messages in thread
From: Michael Tidwell @ 2025-04-30  3:01 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 4046 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 5247 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-04-30  3:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-04-29 22:38 [bitcoindev] Introducing Hourglass Hunter Beast
2025-04-30  3:01 ` [bitcoindev] " Michael Tidwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox