From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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.

Putting out some thoughts with the assumption this will one day be p= ossible*

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.

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 />Here are a few hypothetical scenarios to consider of many regarding mi= ning pools and QC sig producing entities:

- 1. Sigs become publi= c:
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.

- 2. Single En= tity rush spends:
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.

- 3. Bidding war from multiple QC'ers:
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.

- 4. Patient Miner:
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.

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.)
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.
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 funds. The specification is pretty simple, but the motivation and = justification for it is a bit longer.


Feedback welcome!

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegroups.com.
------=_Part_1179_776939331.1745982069244-- ------=_Part_1178_556760284.1745982069244--