path: root/1f/c645c712a45f878eaeaf5fda6d1aa54694c209

Delivery-date: Thu, 01 May 2025 08:56:15 -0700
Received: from mail-qt1-f190.google.com ([209.85.160.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDFIP6H73EBBBFFTZ3AAMGQE3I6P6RY@googlegroups.com>)
	id 1uAWGj-0002jL-R8
	for bitcoindev@gnusha.org; Thu, 01 May 2025 08:56:15 -0700
Received: by mail-qt1-f190.google.com with SMTP id d75a77b69052e-476870bad3bsf17443111cf.3
        for <bitcoindev@gnusha.org>; Thu, 01 May 2025 08:56:14 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746114968; cv=pass;
        d=google.com; s=arc-20240605;
        b=cPacqAEn44sbM0ruQ/IKBoJiUC4hTlbiFshYp9q2RHdyIwZuS8EvOGf20U1B4JZxlb
         GJAdL+G1MuPWFOMqsY20AX7fKbieGqVQdBdvYyrw1zvHJq4neCkTXKX3mHT2VuN00Kd1
         rcbfSloE7yaCMqhjsowtIRlc5+KGJIXgLvNxdpTrdMfMVJnQKkATc8/7qZCysrHfnIij
         TbUSSBqmoaz+6rGW8JsVPVSNSjA9oDYmaZDAfpTSN2QYIvm44Jako5S/zBkPlo8n29GC
         MiIDpl4VD4ycaeEAaqDbGNKY93k2xtEIe/s0tA4v2/3v/4BtNszd7lb+JHiYEOWqIMrL
         4fKg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=YLRrcQ4XIDzMEdhdyM8xd+fY6MTT79lujkY4tqwfpF0=;
        fh=nmHEyA8I7e9buHdNGjA9x2DqremkB+UqDzEFZZgKVDw=;
        b=l3hLQHQsg3jEwnkOcnMK0pW8aFpU+x1aXgK+pY7jm3mOBc/GBpeoUsv5Adz27eaH8+
         MjVFK8Dl2QO2P+BX8617MxpxP4m7P4bK+U7n2GEedwX6hu5fSE2VaHR1euden3DOFEuw
         MYZa+HTLR2p8lcQng69iUotLJ/HQokb45FwyEXPBRR5Pr9VyI4JQ3i5eReFcEAIugDxE
         hBZyzrlYZRfc8BMjkXXXghuOWIVawEY9vtpJJ6ClvnDIlasrg3DwDEwRN5xtx6+WGf41
         odhTWpgOnEvh6aQa8MVJlEd29oXrF3wyfTwChXEyT7WTW26r5tCLPmypboXQFyC2fUbg
         wR8w==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=eLMrG0y3;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746114968; x=1746719768; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=YLRrcQ4XIDzMEdhdyM8xd+fY6MTT79lujkY4tqwfpF0=;
        b=vleY6nHy+MOuVchJ64DiULlyFsy4TA6geHc/qJc43/5NGO3zTCCLxD4PexW1XnNC4s
         Y0O3WbOV0A77rKMO8YEjL+z0Pk/awWtqSPq5Wx1UUWHUzyK0gPENNxsQ56MhcGqkq04N
         eZyYIJ7LJP/JgYgFjMQ15nxFI7VVVds1IuSH8vUryTJRZHqak6qftldXi79iP+FVoDBl
         qKY/9oPWsqVcar5xtvvuk2v8L3WpR6xHWK9MvUpPxrnIl+ZsihV42UCJmSkthvZ0L7B9
         G+hzy/7riVJciO7smckRUAtnHA88ThZfYcS5mXHVtlfqzXnMDuJ8Xs4LTodRfap8ldEE
         paoA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746114968; x=1746719768; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=YLRrcQ4XIDzMEdhdyM8xd+fY6MTT79lujkY4tqwfpF0=;
        b=jL9LwgBdfqkr+0pDzrDLHCADXzV5cuIbbL9ziRL6Tn6XISFx724sb83hnd9oQYNn4u
         RGCU3KqpJL0mWRY8Xzsu22ud85MH5LOijKL5XEIMTkW1JtspWd92eu5Tc6idcKt3lgAd
         iZ5/+yMThH3W0Pm/AcAd6dLe+I4I8SZS5tN/A8lL26oKafRbq5NR7rE9XBasWYlpFUM/
         7wBDt70AlWoOSGfzFDse7x/vBPTZyv/6ThVVaAdIt1hkfvc6AwPNecAZM0QUZC4iDjg4
         RtEC7bdlDc8HbSxutuWvi8NBIlecDcrGTeSPfrVTYmLveZoqgKyyJiBOpXsfalBMaKxV
         7iAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746114968; x=1746719768;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=YLRrcQ4XIDzMEdhdyM8xd+fY6MTT79lujkY4tqwfpF0=;
        b=rVE7sxOamRKcmpWcATqxmRhLiO/0T6kpq5CRjIRqihbEkGUYTu90BuQcoqpRwGaXQ4
         b5nHIved+5eofOELgkUfRB1ULm5rD1bcw6ZqaodOVQtZA+Vi8lfJiIw7QpnaXiiBZNBb
         PcdqMCe8pVMRqJwjWhgYifMFp6CVXAaEZFi7YCjVLls8XGFmY7HRYd+x+jTeR/v7iMCV
         Ngth/T1OjZLHxvSyf0IxcxeDq8n3y7OlKfxvNAxi7jTPHTmX2oeZ5zI9sFCN4R/qgtJu
         Buv+MdrfICZ/EjRbPUroAjJAo9Zatf98lVDnI0lnOF6Q+BipJSc5IUW49aNzeVZ6iUqV
         hp+w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVanxaix+alt36Cx39dbDA0Xs54Iw/iPKpvZ8u2jzERoluRoLhhlpEBSidejwjQt1yUNC84awfHMx2m@gnusha.org
X-Gm-Message-State: AOJu0YwNvk5q0diQI8VHt+3jtt9LjEssPLJlmqSXoGBamcR2QxLp80j5
	T1XiP2vV6jlQE1HCu1nN7Ok2loPY08RCcoIj72YTYvv5CkRJfO7Q
X-Google-Smtp-Source: AGHT+IHXjT2jaui/PhYkj1ZwC5GQGeKRKLPCQS1faS2LkRHo/4m2JHUbHX1nlpzyjTTmwqNjrHfzJA==
X-Received: by 2002:a05:622a:1e0f:b0:467:5da6:8096 with SMTP id d75a77b69052e-48b21c6b022mr51849351cf.44.1746114967539;
        Thu, 01 May 2025 08:56:07 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHnMNoFHa9ZwX+sxKtA+morSLyDXEXsAqaZspEPJWQRxw==
Received: by 2002:ac8:4653:0:b0:476:8286:80fb with SMTP id d75a77b69052e-48ad89d0fa8ls14947721cf.2.-pod-prod-01-us;
 Thu, 01 May 2025 08:56:04 -0700 (PDT)
X-Received: by 2002:a05:620a:2712:b0:7ca:ca5d:779e with SMTP id af79cd13be357-7cacf013603mr399522985a.47.1746114963956;
        Thu, 01 May 2025 08:56:03 -0700 (PDT)
Received: by 2002:ab3:488a:0:b0:293:3256:5107 with SMTP id a1c4a302cd1d6-2acb1ad6145msc7a;
        Thu, 1 May 2025 04:39:00 -0700 (PDT)
X-Received: by 2002:a2e:bd02:0:b0:30b:ecfc:78c6 with SMTP id 38308e7fff4ca-31fc1d9e651mr6757821fa.1.1746099538553;
        Thu, 01 May 2025 04:38:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746099538; cv=none;
        d=google.com; s=arc-20240605;
        b=DQyKL7b+FJ9PaXoeU0QSroa5dQIABRC58R4HIxv3CEfrhZ1Z3/NVC0RINIeJFfUL/0
         7b2kLSebMPlq0jM0+78VG6QbBSFEetQpgmVHqrtZmyDjWYIuF/jeQIQjQ2eW0XowQUY/
         KRpv2cFQufOkLF8/vti8Cyso3a2h8ofMVSQkjRv6Gk1Vgx5vivJGY1Y8TkY3eNxkvOUI
         Eqvk15oV0Xn54lDTY8okZFPtNGWV/vY8ZyU4WMJ244Vns5F02JCHBDzlZkm2qR7eN7r5
         hrLk8Vl5YNpXrclWyw6OU72ZQ9cHtaDFugnirOATxnU+bbUTxaXogkQzT5ZsF4jxWU0L
         aJhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=61j+IL+zPKf/qcwu48lGy3uOYlJ3TwWeVq9U9zJTn9A=;
        fh=vwK/tZt5NP0eeFP8Coyy2yZmOg14wU4Tqa0a14tCAu0=;
        b=AwvpbF2UumpNk2CLU3hDZguJuMRzNm2OP0fWitUaX1uwv2qGbaq8QgW1iCjhYxpu5a
         06FqrqY+eMrvimOg4gqYsXAalY1yK9FhzH9pXYhOA2pKEGFr3mK6+F947zizS5vpJ5e+
         ZQHpuBMeTIDOfmV8ymn06ZCTin5sH2a9l3ryed1VNlQCEtXK8MDs0ppVmqMVimymF86C
         Nfb37/o0VdG3vxf38VvBrUtAREEHMXlcaRf5UsPUGCx+TFbV/Q1jwoi+Bb/CM8g67ydD
         7LJ8XAJlVlWCLI6pGxIYU4OJPBuKx6rElFbEoXZvzhtqOxLtSX3K3uiIWfGFJWfj5J0p
         Hs8Q==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=eLMrG0y3;
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com. [2a00:1450:4864:20::130])
        by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3202a5b2067si182731fa.5.2025.05.01.04.38.58
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 01 May 2025 04:38:58 -0700 (PDT)
Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) client-ip=2a00:1450:4864:20::130;
Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-549967c72bcso931115e87.3
        for <bitcoindev@googlegroups.com>; Thu, 01 May 2025 04:38:58 -0700 (PDT)
X-Gm-Gg: ASbGncsGuNGHRnzgV9R8kED8dWFmvCFZnrNsHxfHjI3MXEyew8KZ3KZjFcma6CJpo5+
	7Nyx5OhdYWD9MiLjZeCFSZ5zio7UShOGMenzFQEirX7BbRpUZrlrR+Zwmmdz3aqBkOVGlfGrISS
	H1jhK9UpCcZaZe2PrO76ma
X-Received: by 2002:a05:6512:b90:b0:545:fad:a747 with SMTP id
 2adb3069b0e04-54ea7639c4fmr543661e87.5.1746099537829; Thu, 01 May 2025
 04:38:57 -0700 (PDT)
MIME-Version: 1.0
References: <db3d0ec4-90b8-44a4-b912-b98ec9083b10n@googlegroups.com> <c3b9617f-b419-4fc0-9a00-5d1866f80920n@googlegroups.com>
In-Reply-To: <c3b9617f-b419-4fc0-9a00-5d1866f80920n@googlegroups.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
Date: Thu, 1 May 2025 07:38:45 -0400
X-Gm-Features: ATxdqUEFDBI8HurEG1DZcmY_a2VOvCfKZd2jzWtqcNlrGSLXM848K4TeTsQAwcg
Message-ID: <CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG+mg@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Introducing Hourglass
To: Michael Tidwell <michael@tidwell.io>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000b1e5530634117a36"
X-Original-Sender: jameson.lopp@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=eLMrG0y3;       spf=pass
 (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::130
 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: 0.0 (/)

--000000000000b1e5530634117a36
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Michael Tidwell <michael@tidwell.i=
o> 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, ther=
e
> will be roughly one cracked key per block thereafter.
>
> Here are a few hypothetical scenarios to consider of many regarding minin=
g
> 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 tim=
e
> 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 o=
wn
> 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 amoun=
t
> 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=E2=80=AFPM UTC-4 Hunter Beast wrote=
:
>
>> This is a proposal to mitigate against potential mass liquidation of P2P=
K
>> 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.mediawi=
ki
>>
>> 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-5d18=
66f80920n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/c3b9617f-b419-4fc0-9a00-5d1=
866f80920n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG%2Bmg%40mail.gmail.com.

--000000000000b1e5530634117a36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think this could benefit from a lot more blockchain anal=
ysis in order to support the claim that it will reduce economic volatility.=
 On its surface it feels like a half measure.<div><br></div><div>Sure, requ=
iring 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, t=
he machines doing the cracking can crack a key in less than 10 minutes.</di=
v><div><br></div><div>However, a rational quantum adversary will seek to ma=
ximize their revenue. For example, the most valuable likely lost funds are=
=C2=A012ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has 31,000 BTC spread across=
 only a handful of UTXOs. It&#39;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 qua=
ntum 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.</div><div><br></div=
><div>Moving on to P2PK specifically, I&#39;d expect a similar issue of fro=
nt-loaded volatility once a quantum adversary runs through the high value r=
eused addresses that haven&#39;t migrated to a quantum safe scheme. Take, f=
or example, James Howells&#39; funds at=C2=A0198aMn6ZYAczwrE5NvNTUMyJ5qkfy4=
g3Hi - 8,000 BTC spread out across just 16 UTXOs, which would be spendable =
in a 3 hour timeframe in this proposal.</div></div><br><div class=3D"gmail_=
quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, =
Apr 29, 2025 at 11:26=E2=80=AFPM Michael Tidwell &lt;<a href=3D"mailto:mich=
ael@tidwell.io">michael@tidwell.io</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">I&#39;m much more in favor of this approa=
ch vs freezing/burning the coins.<br><br>Putting out some thoughts with the=
 assumption this will one day be possible*<br><br>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&#39;t lead to any c=
lear bias. Like the BIP explains, deciding which coins should be locked is =
a dangerous precedent. I&#39;m more in favor of cryptographic romanticism v=
s authoritarian UTXO adjudicating. Early p2pk were not created with the ide=
a 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.<br><br>From my search, ther=
e&#39;s roughly ~45,700 P2PK outputs. I don&#39;t think the address count m=
atters here. We&#39;re looking at nearly one year&#39;s worth of UTXOs (~31=
7 days), assuming a scenario where, once a key is cracked, there will be ro=
ughly one cracked key per block thereafter.<br><br>Here are a few hypotheti=
cal scenarios to consider of many regarding mining pools and QC sig produci=
ng entities:<br><br>- 1. Sigs become public:<br><span style=3D"white-space:=
pre-wrap">	</span>QC sigs become easy to produce and commoditized, freely a=
vailable for every miner to pull from. Mining pools can arbitrarily select =
the most profitable signatures for their blocks. Given the relatively short=
ish time window between becoming available and being commoditized, I think =
this is unlikely.<br><br>- 2. Single Entity rush spends:<br><span style=3D"=
white-space:pre-wrap">	</span>A single entity generates QC signatures and t=
ries to rapidly flip the UTXOs while having their first mover competitive e=
dge. They either broadcast to the mempool, partner with miners, or mine dir=
ectly. This creates potential miner collusion if P2PK fees remain low, pres=
suring the QC entity to raise fees and incentivize miners before their comp=
etitive advantage expires and others catch up.<br><br>- 3. Bidding war from=
 multiple QC&#39;ers:<br><span style=3D"white-space:pre-wrap">	</span>QC si=
gs produced by multiple entities, leading to potential bidding wars as sugg=
ested by BIP scenario. However, if the entities controlling the signatures =
are few, collusion to keep fees low and maximize profits elsewhere imo is l=
ikely to occur. This scenario would somewhat counterbalance scenario (2) ab=
ove.<br><br>- 4. Patient Miner:<br><span style=3D"white-space:pre-wrap">	</=
span>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.<br><br>I&#39;ve discussed this id=
ea off-band and heard concerns regarding MEV specifically, (i.e. miners nee=
ding QC partnerships or capabilities to remain competitive.)<br>Considering=
 the approximately 1 year exploit window, and an unknown amount of time in =
the future when this would occur, it&#39;s not clear that there would be si=
gnificant MEV concerns during or afterwards for the (post QC phase). I cons=
ider 1 year in Bitcoin to be a relatively short time period that could be s=
tomached as a &quot;phase&quot;. Due to potential market panic and pressure=
 from QC stakeholders, it&#39;s unlikely an entity would choose a long-term=
 approach (e.g., 3-4+ years) to exploit these transactions. Instead, they&#=
39;d likely pay fees promptly to outpace other people about to make breakth=
roughs in QC.<div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_at=
tr">On Tuesday, April 29, 2025 at 7:08:16=E2=80=AFPM UTC-4 Hunter Beast wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is a pr=
oposal to mitigate against potential mass liquidation of P2PK funds. The sp=
ecification is pretty simple, but the motivation and justification for it i=
s a bit longer.<div><br></div><div><a aria-label=3D"Link https://github.com=
/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki" href=3D"https://g=
ithub.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki" rel=3D"n=
oreferrer noopener nofollow" title=3D"https://github.com/cryptoquick/bips/b=
lob/hourglass/bip-hourglass.mediawiki" target=3D"_blank">https://github.com=
/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki</a></div><div><br>=
</div><div>Feedback welcome!</div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegrou=
ps.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG%2Bmg%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG%2Bmg%40ma=
il.gmail.com</a>.<br />

--000000000000b1e5530634117a36--