> Bitcoin should not have an in-protocol plunge protection mechanism, and certainly not one that artificially restricts people's ability to spend their coins. I encourage you to withdraw this proposal, for the sake of bitcoin's integrity and utility as a p2p electronic cash system.
The (time) limit is only applicable to legacy P2PK addresses. Anyone can move their funds to modern SegWit/Taproot addresses and continue without any such limit. You are free to insist on using legacy P2PK addresses as you wish, freely, but doing so would put a spending (time) limit much like current banking KYC limits. Again, insisting on keeping your BTC in specifically legacy P2PK addresses would lead to this (time) limit. All other addresses are unaffected.
Admittedly, the actual value is arbitrary, but it's very easy to relay conceptually which helps communicate the concept and dissuade this particular branch of quantum FUD. Fundamentally, it's a trade off between how quickly the entire set can be liquidated (if keys are cracked in advance) and how long and individual original keyholder has to wait to be able to exercise dominion over their P2PK coins. In addition to memetics, the 1 BTC amount should provide a very lengthy liquidation period assuming most P2PK keys are lost and cannot be moved prior to implementation.On Monday, February 16, 2026 at 5:11:09 PM UTC-5 Jameson Lopp wrote:Bitcoin is ultimately a system of rules that are enforced by those who use the system and hold the keys to spend UTXOs. As such, if a sufficiently large cohort of economic power within the system is interested in protecting itself against massive liquidation events from malicious actors who arguably are not the rightful owners of UTXOs, the incentives are in place for them to do something about it.I like Hourglass V2 a lot more than V1. My primary complaint is that 1 BTC per block is somewhat arbitrary. It would be interesting to point to the on-chain statistics of what P2PK UTXO spend volume we have seen in recent years.
Additionally, in the context of my own migration BIP, Hourglass V2 could be complementary to the concept of offering a ZK quantum safe spending option for folks who fail to migrate UTXOs to quantum safe scripts before a set deadline, given that these old P2PK outputs do not belong to HD wallets and thus the owners would be incapable of constructing a ZK proof of HD wallet ownership.On Fri, Feb 13, 2026 at 5:12 PM Light <bitco...@lightco.in> wrote:Bitcoin should not have an in-protocol plunge protection mechanism, and certainly not one that artificially restricts people's ability to spend their coins. I encourage you to withdraw this proposal, for the sake of bitcoin's integrity and utility as a p2p electronic cash system.
On Tue, Feb 10, 2026, at 3:47 PM, Mike Casey wrote:
> In response to feedback, the Hourglass proposal to mitigate against
> potential mass liquidation of P2PK funds has been enhanced to further
> limit spend amounts from such outputs to only 1 bitcoin per block.
> https://github.com/cryptoquick/bips/blob/hourglass-v2/bip-hourglass-v2.mediawiki
>
> Prior discussion of the original Hourglass proposal:
> https://groups.google.com/g/bitcoindev/c/zmg3U117aNc/m/lDCMs9j7EAAJ
>
> Thoughts & 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+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/9336f5a4-5c28-4c1b-af29-a8462b7a9377n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/9336f5a4-5c28-4c1b-af29-a8462b7a9377n%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+...@googlegroups.com.To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/57bd09bc-1c1b-4605-82f9-65b6b61cf8a2%40app.fastmail.com.