Introducing Hourglass

Introducing Hourglass
2025-04-30  3:01 ` [bitcoindev] " Michael Tidwell
  2025-05-02 15:45 ` Francis Pouliot
  
From: Hunter Beast @ 2025-04-29 22:38 UTC ( / )
  To: Bitcoin Development Mailing List




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.
2025-04-29 22:38 [bitcoindev] Introducing Hourglass Hunter Beast

  2025-05-01 11:38   ` Jameson Lopp
  2025-05-01 17:38   ` Nagaev Boris
  2025-05-02 15:45 ` Francis Pouliot
  
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	[|nested]
2025-04-30  3:01 ` [bitcoindev] " Michael Tidwell

  2025-05-01 17:38   ` Nagaev Boris
  
From: Jameson Lopp @ 2025-05-01 11:38 UTC (permalink / raw)
  To: Michael Tidwell;  Bitcoin Development Mailing List

[-- 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 --]

 permalink raw reply	[|nested]
2025-04-30  3:01 ` [bitcoindev] " Michael Tidwell
  2025-05-01 11:38   ` Jameson Lopp

  2025-05-01 18:23     ` Agustin Cruz
  
From: Nagaev Boris @ 2025-05-01 17:38 UTC (permalink / raw)
  To: Michael Tidwell;  Bitcoin Development Mailing List

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.


 permalink raw reply	[|nested]
2025-05-01 17:38   ` Nagaev Boris

  2025-05-02 13:58       ` Saint Wenhao
  
From: Agustin Cruz @ 2025-05-01 18:23 UTC (permalink / raw)
  To: Nagaev Boris;  Michael Tidwell, Bitcoin Development Mailing List

[-- 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 --]

 permalink raw reply	[|nested]
2025-05-01 18:23     ` Agustin Cruz

  
From: Saint Wenhao @ 2025-05-02 13:58 UTC (permalink / raw)
  To: Agustin Cruz
  Cc: Nagaev Boris, Michael Tidwell, Bitcoin Development Mailing List

[-- 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 --]

 permalink raw reply	[|nested]
2025-04-29 22:38 [bitcoindev] Introducing Hourglass Hunter Beast
  2025-04-30  3:01 ` [bitcoindev] " Michael Tidwell

  2025-05-04  6:00   ` Hunter Beast
  
From: Francis Pouliot @ 2025-05-02 15:45 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


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


Concept NACK.

1.7 million Bitcoin represents possibly about 1 week of global trading 
volumes. Even assuming it is 1-2 months of trading volumes, the market can 
absorb.

Trying to manage the Bitcoin price via spending restrictions is a terrible 
idea.

In any case, the Bitcoin price routinely drops by upwards of 85%. It is not 
a security concern. Price volatility is not a security. 
On Tuesday, April 29, 2025 at 5:08:16 PM UTC-6 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/c4094fa8-8ec0-411c-8a67-80b8fc6282fdn%40googlegroups.com.

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

 permalink raw reply	[|nested]
2025-05-02 15:45 ` Francis Pouliot

  
From: Hunter Beast @ 2025-05-04  6:00 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


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

Trading volume is a good perspective to view this through, actually. If an 
attacker decides to consolidate immediately, they could do so within just a 
couple hours and suppress the Bitcoin price for a long time.

> 1.7 million Bitcoin represents possibly about 1 week of global trading 
volumes. Even assuming it is 1-2 months of trading volumes, the market can 
absorb.

Hourglass spreads that 1 week of trading volume over a minimum of 8 months, 
possibly more.

> Trying to manage the Bitcoin price via spending restrictions is a 
terrible idea.

While I generally agree with this sentence, I think P2PK coins are an 
exceptional case.

> In any case, the Bitcoin price routinely drops by upwards of 85%. It is 
not a security concern. Price volatility is not a security.

Price volatility absolutely impacts security, and this would be an 
unprecedented event. We also haven't seen an 85% price drop in a long time.

On Saturday, May 3, 2025 at 5:55:28 AM UTC-6 Francis Pouliot wrote:

>
> Concept NACK.
>
> 1.7 million Bitcoin represents possibly about 1 week of global trading 
> volumes. Even assuming it is 1-2 months of trading volumes, the market can 
> absorb.
>
> Trying to manage the Bitcoin price via spending restrictions is a terrible 
> idea.
>
> In any case, the Bitcoin price routinely drops by upwards of 85%. It is 
> not a security concern. Price volatility is not a security. 
> On Tuesday, April 29, 2025 at 5:08:16 PM UTC-6 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/4f35a82a-bedb-4d4d-9de2-2dbc340b18acn%40googlegroups.com.

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

 permalink raw reply	[|nested]