YKYC but P2PK has been deprecated since a little in 2013 after I joined
Bitcoin as one of the silent masses around 2010. What does 13 years of
"deprecated" mean?

Fix the cryptography, remove the unlimited 'first class' status of the
ancient system. Maintenance should have a clear path to removing cruft,
insecurities and deprecated systems. P2PK is all 3.
"Your keys, Quantum Attacker Crypto" is the alternative.

On Tue, Mar 3, 2026, 22:25 'Brandon Black' via Bitcoin Development Mailing
List <bitcoindev@googlegroups.com> wrote:

> Hi Mike, list.
>
> My personal response to this type of proposal remains a firm, and
> time-unlimited, "no".
>
> There are, broadly speaking, two possible ways in which secp256k1
> breaks: Gradually and suddenly.
>
> If it's gradually then the risks to P2PK, P2TR, and public public key
> (lol) coins grows gradually, most likely with some large outputs being
> stolen first and liquidated in some gradual way (because the first actor
> to have access to the break is likely a low time preference entity who
> doesn't want to crash the price). Moreover, assuming a gradual break, we
> will have long since deployed an alternative cryptosystem and everyone
> will have had ample time to migrate. Those coins not migrated are fair
> game.
>
> If it breaks suddenly, that could put us in a situation where nobody has
> had a chance to migrate their coins AND the type of actors first gaining
> access to the coins are more likely to be low time preference dumpers
> who will fight each other for the coins using perverse miner incentives
> to protect some residual value. This itself would threaten the very
> tenability of the system.
>
>
> Bitcoin has long held the philosophy of NYKNYC which implies the
> reverse: YKYC. If we decided to break this for any but the most imminent
> and obvious destruction of the system, we have defeated the system's
> very raison d'être. In other words, the only time we should limit or
> disable an old cryptosystem on bitcoin is in the greatest extremity of
> an immediate and total break of the cryptography wherein participants
> have not had time to migrate and the break is instantly widespread.
>
> So, unless someone has access to secret evidence that secp256k1 is
> already broken (in which case we should be disabling all such signatures
> entirely, not trickling them through) we should absolutely not consider
> restricting the property rights of those using any secp256k1 signature.
> This is regardless of how we feel about public keys being public which
> is an entirely other topic.
>
> For me to take a proposal of this general nature seriously, it would
> have to treat all secp256k1-protected outputs the same (as the
> supposed security of hashed output types relies strictly on public
> information being secret).
>
> All the best,
>
> --
> --Brandon
>
> On 2026-02-10 (Tue) at 12:47:22 -0800, 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.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/aadRUrmtko-uyvt2%40console.
>

-- 
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/CA%2B7C%2BcaG37zBNYPw6_qjtN6zyXh6_CSvc%3DhjSCEp4kqnEu0YWg%40mail.gmail.com.