From: Light <bitcoin-dev@lightco.in>
To: "Jameson Lopp" <jameson.lopp@gmail.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Hourglass V2 Update
Date: Mon, 16 Feb 2026 19:31:41 -0500 [thread overview]
Message-ID: <536c8559-39c4-4f63-a8a3-fd407253e886@app.fastmail.com> (raw)
In-Reply-To: <CADL_X_eb8byZs3VKORoUzaPoBvguSbxJ=KyKifsQFWFqyqHeRA@mail.gmail.com>
Hi Jameson,
Just as "the incentives are in place" for short term greedy participants to make their case for full node runners to follow them off a cliff, so are the incentives in place for those with longer term perspectives to encourage authors of confiscatory proposals to abandon them, and encourage the rest of the community to reject them as well.[1]
The people who appeal to short-term incentives to call in the plunge protection squad fail to see that in doing so they irreparably damage the long term value of their coins (and create extra work for those of us with lower time preferences who must now consider the logistics of defensive forking) by undermining one of the foundational principles that gives their coins value to begin with.
There is a difference between "can" and "should" and the norm around here is pretty well established that bitcoin protocol developers (and the broader community of full node runners) "should not" interfere with existing spending conditions, even if they are believed to be insecure. Key (mis)management is an application layer concern, not a consensus layer concern. If you disagree, where is your proposal for freezing coins held on exchanges? You have already written about the risks posed by such custody arrangements, and this is a much more imminent threat than the specter of a CRQC.[2]
[1] To say nothing of the incentives of the vulnerable keyholders and the CRQC operators, but that is a secondary and more academic topic compared to the discussion about principles and long term system integrity.
[2] https://blog.casa.io/the-custodian-menace
On Mon, Feb 16, 2026, at 5:03 PM, 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 <bitcoin-dev@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+unsubscribe@googlegroups.com <mailto:bitcoindev%2Bunsubscribe@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+unsubscribe@googlegroups.com <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>.
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/57bd09bc-1c1b-4605-82f9-65b6b61cf8a2%40app.fastmail.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/536c8559-39c4-4f63-a8a3-fd407253e886%40app.fastmail.com.
next prev parent reply other threads:[~2026-03-02 23:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-10 20:47 Mike Casey
2026-02-13 22:06 ` Light
2026-02-16 22:03 ` Jameson Lopp
2026-02-17 0:31 ` Light [this message]
2026-02-17 13:02 ` Garlo Nicon
2026-02-17 13:24 ` Isabel Foxen Duke
2026-02-23 18:47 ` Isabel Foxen Duke
2026-02-25 14:39 ` Bob Burnett
2026-02-25 16:46 ` Jameson Lopp
2026-02-18 14:33 ` Mike Casey
2026-02-19 3:26 ` Alex
2026-02-21 6:22 ` neonrooks
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=536c8559-39c4-4f63-a8a3-fd407253e886@app.fastmail.com \
--to=bitcoin-dev@lightco.in \
--cc=bitcoindev@googlegroups.com \
--cc=jameson.lopp@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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