From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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: In-Reply-To: From: Jameson Lopp Date: Thu, 1 May 2025 07:38:45 -0400 X-Gm-Features: ATxdqUEFDBI8HurEG1DZcmY_a2VOvCfKZd2jzWtqcNlrGSLXM848K4TeTsQAwcg Message-ID: Subject: Re: [bitcoindev] Re: Introducing Hourglass To: Michael Tidwell Cc: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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 > > . > --=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
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.

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.

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'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.

Moving on to P2PK specifically, I'd expect a similar issue of fro= nt-loaded volatility once a quantum adversary runs through the high value r= eused addresses that haven't migrated to a quantum safe scheme. Take, f= or example, James Howells' 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.

On Tue, = Apr 29, 2025 at 11:26=E2=80=AFPM Michael Tidwell <michael@tidwell.io> wrote:
I'm much more in favor of this approa= ch 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 c= lear bias. Like the BIP explains, deciding which coins should be locked is = a dangerous precedent. I'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.

From my search, ther= e's roughly ~45,700 P2PK outputs. I don't think the address count m= atters here. We're looking at nearly one year'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.

Here are a few hypotheti= cal scenarios to consider of many regarding mining pools and QC sig produci= ng entities:

- 1. Sigs become public:
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.

- 2. Single Entity rush spends:
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.

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

- 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 = own blocks to maximize long-term profits.

I'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.)
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 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 "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&#= 39;d likely pay fees promptly to outpace other people about to make breakth= roughs in QC.
On Tuesday, April 29, 2025 at 7:08:16=E2=80=AFPM UTC-4 Hunter Beast wro= te:
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.


=
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/c3b9617f-b419-4fc0-9a00-5d1866f80920n%40googlegrou= ps.com.

--
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/bitcoindev/CADL_X_eDtRS1FCqo1g7TMzNTujhmDGPMAw21p2ej9iXQPXG%2Bmg%40ma= il.gmail.com.
--000000000000b1e5530634117a36--