path: root/9f/5dd270567c1c02fb3486fa631cf00fc811fcce

Delivery-date: Tue, 29 Apr 2025 20:27:01 -0700
Received: from mail-yw1-f192.google.com ([209.85.128.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDAKR25Q7ANBB6FQY3AAMGQEWAPSWXI@googlegroups.com>)
	id 1u9y68-0001Df-Ar
	for bitcoindev@gnusha.org; Tue, 29 Apr 2025 20:27:01 -0700
Received: by mail-yw1-f192.google.com with SMTP id 00721157ae682-7082d8db9bcsf95097697b3.3
        for <bitcoindev@gnusha.org>; Tue, 29 Apr 2025 20:27:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1745983614; x=1746588414; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=+Aqg66l/fdD/smD1DAp8IHrfn+tUKkExavXW3dZGQwo=;
        b=umMRhYEUkghpVxcPrDuNv6I0RPjOGgeg6LC4SloRnHcqmSNI6TZ7gvumb60P+IIMtW
         xT0VmvaRKYUQ3gCrodgxeuLcJJ/O24q1ODhYmVxIkWkF/m9L4GBJRCynVBzYcIVr90Pp
         6m4LbXwE9Xq/k1b0mSlKXC5YEsMTDhVhLjz6y2JkeDpwVP5HqdiQVGnKk41UlyEpZEiV
         NKo4ka5e0UTZfZE9Itz8v6BnCl6RP25HX+3w5/Jjt5PlBbb11ma27Rt0S8tEIIjdRGZY
         22qfBDSzMNpgULcpTMTdyB819b7IHiC2MGVHIs68f3r50yL917pIIo5agmoY1eV7BQzE
         Gp0g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1745983614; x=1746588414; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+Aqg66l/fdD/smD1DAp8IHrfn+tUKkExavXW3dZGQwo=;
        b=IcvUZwYwqGDYIrAB4WzZKtgApENUuyXd0dbduAQpWLD2EDyD71OYZI+Z0z2DGcyDe+
         UuSXqsU2Wa+NH2WC8scqRjHSZyvlnBoXRR5w9xP5nr4yu8WHhkYFH+TTt99q6LQxBAha
         /W4Vwuv4uGykJ1RtWclEJhJUefGn/QI+UbblQJy/u2pIf/ayqNW2JE/8zH3bQ33HSu6G
         jBvL+fsdCvd8Iqi4aM0FyXOKyY1Z11I+ZpCwR8lrYmaRtgNz19ydHRBYxeYhMZFQkZ2m
         KNVikOhGQ1OubbSQer0NUBcznxdTUcDv9M3EHEyg1xz4pbl9PIeK0oZ2dTOxJHoat/Mb
         +dUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1745983614; x=1746588414;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+Aqg66l/fdD/smD1DAp8IHrfn+tUKkExavXW3dZGQwo=;
        b=Zcpk/+HK3Aeuutcr6DvdLzxmtmL9+gZ7kmD4N1NH0xdWM6gnErxmW/88TFqjsAMRqs
         vm56VrN19bfMnL2N+y1FPC1eFAToy2tYlYow311nSRoJnEZIywE8LQd3GmzyCeab+lkY
         bKsUmCUABFsmZYn9PZVHDwiaG/gr2Xh4LHriBtgDYXenazJgb0B/+IGkNLll0AJXJ5se
         WNbXtMiMdPX/v8os3NkkIG7KlwkSPDQ2e9gT+Pkc9EPmTe9r09a/Vp7DqD2lJC646/eE
         IK+FhkOoE7dSebYqDJsBee86Cu0Dntee2DLVCrHHP9GzJm0pAbZvp4Mal28lK69mHzMs
         2FLw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUjuMvfXTI5JyoqLc3Z/riAaqpdITbzYVNS6rAokk88CORbGZpfUCzQPVjIDSnaca+G8BL2O+bwwGsu@gnusha.org
X-Gm-Message-State: AOJu0YyTevzlYFV8tGDZLs/oRUytb10DUfB9cjuGYpIxDwO80LFiEC2K
	ih9IQ/U9SHNAIqL5qqP3udYRPVRr5DKoF+oyoqYNGOk0wbAkHH9K
X-Google-Smtp-Source: AGHT+IGrtILIQqr8AmPspkfARbOU6bucOJ6F8I7Y9423Cw1uHqIQkQzFGIPk5jUMvjI72X1ie9X/YA==
X-Received: by 2002:a05:6902:709:b0:e73:17fe:d6b7 with SMTP id 3f1490d57ef6-e73eaed9b3emr2224329276.22.1745983613976;
        Tue, 29 Apr 2025 20:26:53 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBErmz6IYOhxdoT8WBUdR3WRuE+sjPPsnCp51gmuFqeO0Q==
Received: by 2002:a25:aac1:0:b0:e73:126d:3974 with SMTP id 3f1490d57ef6-e73126d39f9ls1052639276.2.-pod-prod-05-us;
 Tue, 29 Apr 2025 20:26:48 -0700 (PDT)
X-Received: by 2002:a05:690c:a8e:b0:708:170c:a699 with SMTP id 00721157ae682-708ad6bd41bmr17244717b3.27.1745983608595;
        Tue, 29 Apr 2025 20:26:48 -0700 (PDT)
Received: by 2002:a05:690c:9c03:b0:706:b535:945d with SMTP id 00721157ae682-708ab0f15b7ms7b3;
        Tue, 29 Apr 2025 20:01:10 -0700 (PDT)
X-Received: by 2002:a05:690c:9a86:b0:6fb:9b8c:4b50 with SMTP id 00721157ae682-708ad5f35efmr16235217b3.13.1745982069621;
        Tue, 29 Apr 2025 20:01:09 -0700 (PDT)
Date: Tue, 29 Apr 2025 20:01:09 -0700 (PDT)
From: Michael Tidwell <michael@tidwell.io>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <c3b9617f-b419-4fc0-9a00-5d1866f80920n@googlegroups.com>
In-Reply-To: <db3d0ec4-90b8-44a4-b912-b98ec9083b10n@googlegroups.com>
References: <db3d0ec4-90b8-44a4-b912-b98ec9083b10n@googlegroups.com>
Subject: [bitcoindev] Re: Introducing Hourglass
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1178_556760284.1745982069244"
X-Original-Sender: michael@tidwell.io
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.7 (/)

------=_Part_1178_556760284.1745982069244
Content-Type: multipart/alternative; 
	boundary="----=_Part_1179_776939331.1745982069244"

------=_Part_1179_776939331.1745982069244
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=20
considered. Distribution of p2pk coins have pre-determined throttle rules=
=20
that don't lead to any clear bias. Like the BIP explains, deciding which=20
coins should be locked is a dangerous precedent. I'm more in favor of=20
cryptographic romanticism vs authoritarian UTXO adjudicating. Early p2pk=20
were not created with the idea that could be stolen. However imo, it is a=
=20
better in everyway: technical, cultural, moral to allow early, inactive=20
vulnerable coins to be naturally recycled without changing the unlocking=20
script.

From my search, there's roughly ~45,700 P2PK outputs. I don't think the=20
address count matters here. We're looking at nearly one year's worth of=20
UTXOs (~317 days), assuming a scenario where, once a key is cracked, there=
=20
will be roughly one cracked key per block thereafter.

Here are a few hypothetical scenarios to consider of many regarding mining=
=20
pools and QC sig producing entities:

- 1. Sigs become public:
QC sigs become easy to produce and commoditized, freely available for every=
=20
miner to pull from. Mining pools can arbitrarily select the most profitable=
=20
signatures for their blocks. Given the relatively shortish time window=20
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=
=20
while having their first mover competitive edge. They either broadcast to=
=20
the mempool, partner with miners, or mine directly. This creates potential=
=20
miner collusion if P2PK fees remain low, pressuring the QC entity to raise=
=20
fees and incentivize miners before their competitive advantage expires and=
=20
others catch up.

- 3. Bidding war from multiple QC'ers:
QC sigs produced by multiple entities, leading to potential bidding wars as=
=20
suggested by BIP scenario. However, if the entities controlling the=20
signatures are few, collusion to keep fees low and maximize profits=20
elsewhere imo is likely to occur. This scenario would somewhat=20
counterbalance scenario (2) above.

- 4. Patient Miner:
A single QC capable entity, also operating as a miner or partners with a=20
miner, chooses to be patient, including P2PK transactions only in their own=
=20
blocks to maximize long-term profits.

I've discussed this idea off-band and heard concerns regarding MEV=20
specifically, (i.e. miners needing QC partnerships or capabilities to=20
remain competitive.)
Considering the approximately 1 year exploit window, and an unknown amount=
=20
of time in the future when this would occur, it's not clear that there=20
would be significant MEV concerns during or afterwards for the (post QC=20
phase). I consider 1 year in Bitcoin to be a relatively short time period=
=20
that could be stomached as a "phase". Due to potential market panic and=20
pressure from QC stakeholders, it's unlikely an entity would choose a=20
long-term approach (e.g., 3-4+ years) to exploit these transactions.=20
Instead, they'd likely pay fees promptly to outpace other people about to=
=20
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 P2PK=
=20
> funds. The specification is pretty simple, but the motivation and=20
> justification for it is a bit longer.
>
> https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawik=
i
>
> Feedback welcome!
>

--=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/=
c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegroups.com.

------=_Part_1179_776939331.1745982069244
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm much more in favor of this approach vs freezing/burning the coins.<br /=
><br />Putting out some thoughts with the assumption this will one day be p=
ossible*<br /><br />At least at a high level this has some interesting meri=
ts that should be considered. Distribution of p2pk coins have pre-determine=
d 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. Ear=
ly p2pk were not created with the idea that could be stolen. However imo, i=
t is a better in everyway: technical, cultural, moral to allow early, inact=
ive vulnerable coins to be naturally recycled without changing the unlockin=
g script.<br /><br />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 y=
ear'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.<br /><=
br />Here are a few hypothetical scenarios to consider of many regarding mi=
ning pools and QC sig producing entities:<br /><br />- 1. Sigs become publi=
c:<br /><span style=3D"white-space: pre;">	</span>QC sigs become easy to pr=
oduce and commoditized, freely available for every miner to pull from. Mini=
ng pools can arbitrarily select the most profitable signatures for their bl=
ocks. Given the relatively shortish time window between becoming available =
and being commoditized, I think this is unlikely.<br /><br />- 2. Single En=
tity rush spends:<br /><span style=3D"white-space: pre;">	</span>A single e=
ntity generates QC signatures and tries to rapidly flip the UTXOs while hav=
ing their first mover competitive edge. They either broadcast to the mempoo=
l, partner with miners, or mine directly. This creates potential miner coll=
usion if P2PK fees remain low, pressuring the QC entity to raise fees and i=
ncentivize miners before their competitive advantage expires and others cat=
ch up.<br /><br />- 3. Bidding war from multiple QC'ers:<br /><span style=
=3D"white-space: pre;">	</span>QC sigs produced by multiple entities, leadi=
ng 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 som=
ewhat counterbalance scenario (2) above.<br /><br />- 4. Patient Miner:<br =
/><span style=3D"white-space: pre;">	</span>A single QC capable entity, als=
o operating as a miner or partners with a miner, chooses to be patient, inc=
luding P2PK transactions only in their own blocks to maximize long-term pro=
fits.<br /><br />I've discussed this idea off-band and heard concerns regar=
ding MEV specifically, (i.e. miners needing 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's not clear that there would be significant MEV concerns during or after=
wards for the (post QC phase). I consider 1 year in Bitcoin to be a relativ=
ely short time period that could be stomached as a "phase". Due to potentia=
l market panic and pressure from QC stakeholders, it's unlikely an entity w=
ould choose a long-term approach (e.g., 3-4+ years) to exploit these transa=
ctions. Instead, they'd likely pay fees promptly to outpace other people ab=
out to make breakthroughs in QC.<div class=3D"gmail_quote"><div dir=3D"auto=
" class=3D"gmail_attr">On Tuesday, April 29, 2025 at 7:08:16=E2=80=AFPM UTC=
-4 Hunter Beast wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;">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.<div><br></div><div><a aria-label=3D"L=
ink https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediaw=
iki" href=3D"https://github.com/cryptoquick/bips/blob/hourglass/bip-hourgla=
ss.mediawiki" rel=3D"noreferrer noopener nofollow" title=3D"https://github.=
com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki" target=3D"_bla=
nk" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp=
s://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki&amp;=
source=3Dgmail&amp;ust=3D1746066563826000&amp;usg=3DAOvVaw2giG9K6N4Vp-apUi5=
5FDKd">https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.med=
iawiki</a></div><div><br></div><div>Feedback welcome!</div></blockquote></d=
iv>

<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/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegroups.com</a>.<br />

------=_Part_1179_776939331.1745982069244--

------=_Part_1178_556760284.1745982069244--