Delivery-date: Thu, 20 Feb 2025 17:44:43 -0800 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tlI5p-0006Va-5m for bitcoindev@gnusha.org; Thu, 20 Feb 2025 17:44:43 -0800 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-5fcec4e9f78sf1550746eaf.0 for ; Thu, 20 Feb 2025 17:44:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1740102275; cv=pass; d=google.com; s=arc-20240605; b=dF3fTB1OdPHVy6CkrohyYygKw8DrJQ7Wi/MIkOKPEKpdEo144r/DqIzd97ybteGWXt W6Mgv7o+s31YHOtYhgGDe8n7SEYcGaa4o9UifayL3pXTs63xbEzgyk6zk1BxwiteLMOi UZebyJbO4Xrjc83Xx3KPbaysvJnaUQcApBJTAOj3C6qOOGmo34zdlpZN3HG+a/01HOQK QfQrbPROq0Z/1NLVSatLLI24gEhd2U5D7Nvz7Q/uZ7UkjvSTIv2+lG9iIP8HWU11mF7G DzTNXUM3d/9ulZxpeKoOo1y5AKRWs2KVmHJPQ7zwt7e2Y/KCK8EKi5bBRP3dIj2lqfGy Kmpw== 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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; fh=gAtMJRrqKa0+Ac8vA1UafwuL2bn1+9xS5UPPPYKUihw=; b=XqKLcwK4lsL8EaOv8GGDNVx+FGffPEStTPPl43t4WHZafyCs8OYU724M028l79P/HP NKQH0utFEwd+B8H6BSjNS2eBAbp/vNYqvBtGsdFZqz8Y+ludBRZPrYRFYrg/aXZtc5sD EOYYctwiAqrVXUOVVUHsqkLp4QI1EpFf6Vxo+fhTp41Dr9BmLYHoGqthI/Fvx2od3EyR 2TeAgQM4fgXob33HVFB0d1oC2xiV13ja+hpQ8LOkfim4XopHc7AbEJtTyZjprk48bVra HHIneRACHQr7HX1anRGedKJy3WShQy/HJSn6mKSnTl5rX0hJD2saPzesJVx9NMvlzK1x PJUg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=PUpDIxjn; spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::31 as permitted sender) smtp.mailfrom=dustinvonsandwich@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=1740102275; x=1740707075; 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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; b=BtzgJtw3rA6D46TDlTW+7yUx2E1eTORV61TvIUqqIQoJFfYElC/FAGO2mW/BhrEwE9 QVs+GZYcnAXRHjCzimPjbsmFb9kayTlcnU1WKNwY+KZ9CRJE01LOdBfY2Gsl8rR30c33 YzVGYZGvJoKbA6cnCGA+sleo6J/UtJJoLEpA/xvTWHef2cKh5K8jxoJwz/wB45IQY7yH xmy6XB1uZwBCL2V7YeobAiilxZ8qaTzyDw84sJgqsncABbX85kv0GCyeASsRlq2Br/Lz RH1sFEjyzfzkxKjLw+8dUkNN6iTYfkLEjrb70wBY4GYAmWh/CT787wwL5Q5PQasMH0RK bwPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740102275; x=1740707075; 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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; b=N9UKmfatvovoPZ9giv/QNCB7NkY5dUzfRSi1zrOVGM45QZEPpHEW9eGZ9ueLa74ScI eBC1QywsTmzZU8y4mnTsW517r8CUxX2Xdaav3Uto/pCs03ZTU2lbbyf9vudbR3s75AcF oUXLoGPXVbJ6QdXl+WxZNK0GQ+unTWE15VJPmnJ1M3oyekTP8IYT2ZRjeFdJGxoqszs3 HPolrPvXQT6AuKJ6sl0JvN7+Gf02YhYT8zT3enQi0PoFD8431vh/jkRcN61pJ+xd15TD zNSNmyR5umB92Y/MegpnGTV0mWuXVjNS3XXOVohiaCZUXn9g9cQsZdF0MCqFZbywHrtN polg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740102275; x=1740707075; 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=OioOR5e6xe1poTI09IAn8JsValyYZNe4+LrF8elqUK8=; b=Aw9TgszsqF0/BVxha4Fih4CaVjH8D+s4zUQ4mgU/sTKi3QVktcM66LWYHy1Gllzx3S WeqMJ0V+77oNpIXFlfh26DZK6i/xpaVJZvAMEkkKlJWWF7JWObV7kqVKS+FsRGvSOXFe M08P84HAc5jFM8/ptnOIKk6YfTyKTqatHPz5kI2BjxyzTvk/bwrpe0SwEL4jNqkQCh5I o1bNdthY5UJ6JdjV1a/rIMCXrQBIv6u66AJvqetEdZXJwI5slJYhD/0QdIUXTUKcCWYA rz4+6WRZ3ZbOdVwHFnxvrsuxbZzMz3XAdnpbv/chz4RCifEyjt0gaqGtGB/KXDe7S2uK 9gWA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWGqkCXC2dJbrhnHrxRgjjger2o2ie43xhdtF2HgVgVjeP/05KrMKln/kmZD0Wpb9ToO/bJYvqhlffQ@gnusha.org X-Gm-Message-State: AOJu0YxsCL7N55qDh/ZoU5T5S/bpEWPW6H4B5EhZq6axYj9qsuB0HBs6 RJwS3uQw6HikfX/WkqL4O1vJ8MotLX0ti04REB15UPp88M3h/XI3 X-Google-Smtp-Source: AGHT+IGYxCdf+Kt+KkM1YrIP4ZJkF4ubRSFefDw+Okey7RX7VzHjz/rJBPTZgGvDRWmwTsHF/cB81g== X-Received: by 2002:a05:6820:999:b0:5fc:a89b:a340 with SMTP id 006d021491bc7-5fd195d0c6fmr1268215eaf.4.1740102275195; Thu, 20 Feb 2025 17:44:35 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVH8QCAU7FwxtKA9DgaEfFfM6XbkCequ7/1cCYTrPLrSvA== Received: by 2002:a4a:e7ce:0:b0:5fd:13fe:3bec with SMTP id 006d021491bc7-5fd13fe4063ls524284eaf.0.-pod-prod-08-us; Thu, 20 Feb 2025 17:44:32 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWaksE3VCouNOLhTVbiw7CPKz2KxQTXK+FxEqq9g9Aj1OEGsMjAQIXkWYULp2AilgwDuI+GekIA3fDo@googlegroups.com X-Received: by 2002:a05:6808:2e4f:b0:3f3:e3ad:f5bc with SMTP id 5614622812f47-3f4246c2ed1mr1679323b6e.9.1740102272432; Thu, 20 Feb 2025 17:44:32 -0800 (PST) Received: by 2002:aca:100e:0:b0:3f4:4b9:4605 with SMTP id 5614622812f47-3f404b947b7msb6e; Wed, 19 Feb 2025 14:06:00 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVA+6bb1byYcNLAWSl/U4jISGHLgef0qlAKoN1mwvkgh3IIAqFdQmUYE5tENp1cIbeeI8WQ1uPZOn+F@googlegroups.com X-Received: by 2002:a05:6a20:1582:b0:1ee:8520:f979 with SMTP id adf61e73a8af0-1eed4fd395bmr11859183637.36.1740002759075; Wed, 19 Feb 2025 14:05:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1740002759; cv=none; d=google.com; s=arc-20240605; b=f/5RkV9lUpqlQZ4AydxQrdRur2tTX4t7nCUjL4y2y7D8t8QekbzgyTuA5poU6T4T9D iZHfiZeLQCD4++uN5meiCg1ecttGB4TX0ZYn/ueUNlN5jdbcDdUmmjd4vSiJUqUev0A8 EVeyn2QdnWq82Lp66YyuIMVXo1hsAKgie7F3GfP3xsh5U7yTLJyz3v9kKUW08kf2dxaA emb4UKOUBAIKg4JXZo9b+aEtABJ9ECG1Qu4Kr1zhDXQTKdHHxYAIlybwtyc4KzPA9Z5C o9npZ1f5A77PI7NqcB9YITpCnjr4ormkuzOxrbT/oizJqjVAW3kIZq8heSBjSyqJIFl3 inAA== 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=/DqzEZS1VavDOoOuVLVoDELQqHK1gcsUxZp4mjGNKNk=; fh=CZ33CWAh0FKVpq5ZRT+3YYWpgzmPdo5onYCiUZNHaYA=; b=c8oK0R8al4o6vCHup8WQ+S+C9mhz9By99MFVxaEdOWCERcBmL1CMwzgmx5IbsjpMd7 ZToSb4RL1mX8HH4MTYdHFtWpMzHsLGtIrTKe0x793mCUqwcDlIQ24xCzD/EgvahjCnwf wRT+mmCOhBFDWettud7+x7mB7ZK6RB4gOcCUVaXxiP70byfdx3AxHIQXty7vbVa+a33g oTeICGYKy/z2gWfr9hOSkmHXjC0RlZDMcMzsuMpYMnt7QMtMzOblXibNMY90LMEJmF1d Azc5hdEsaMvGv1m9qKg7z8Tz96/Iw9hh55bvn7KQFObJG+H1iDVAma9zz3ku+nVunlXg /wZw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=PUpDIxjn; spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::31 as permitted sender) smtp.mailfrom=dustinvonsandwich@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com. [2001:4860:4864:20::31]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-adb57c5e0aesi631156a12.2.2025.02.19.14.05.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2025 14:05:59 -0800 (PST) Received-SPF: pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::31 as permitted sender) client-ip=2001:4860:4864:20::31; Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-2bc659753d0so129030fac.3 for ; Wed, 19 Feb 2025 14:05:59 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXPncovS3N1Ck80kxqqNGU8HmZfXETgewmpxp9EZjof0QU40so40eiAH7rO+1oRscc5lugSLydo1jiL@googlegroups.com X-Gm-Gg: ASbGnct7kSc/7G87U95iuOsEVzbc+V1YnemTX4yTROQPQT8erqJnjeiXe2PSLtV2l8t pgmnGWQId+BpSwS7vzanbVaCzq/A1Q0dbigtj5sWCYvPf8++gHwBW+rpw6Qr6SluxKvhu7YjqMZ mJw4FgPNTIgn3JX2F5jPpvIMyNnv0y X-Received: by 2002:a05:6870:899b:b0:2b8:e4b9:47a3 with SMTP id 586e51a60fabf-2bd102f08cbmr4193522fac.22.1740002758156; Wed, 19 Feb 2025 14:05:58 -0800 (PST) MIME-Version: 1.0 References: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com> In-Reply-To: From: Dustin Ray Date: Wed, 19 Feb 2025 14:05:47 -0800 X-Gm-Features: AWEUYZneCD7jdBcEAokiEB65SDX-L6K4Om9rUROFA7DeCBdevcBPKJSuDxs-Szw Message-ID: Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration Protocol (QRAMP) BIP To: Agustin Cruz Cc: Hunter Beast , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000004ee7c4062e85f653" X-Original-Sender: Dustinvonsandwich@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=PUpDIxjn; spf=pass (google.com: domain of dustinvonsandwich@gmail.com designates 2001:4860:4864:20::31 as permitted sender) smtp.mailfrom=dustinvonsandwich@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.5 (/) --0000000000004ee7c4062e85f653 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't disagree personally with most of what you're saying except where the real catastrophe lies. Id argue it's catastrophic for the value proposition of a blockchain to effectively seize funds, which is what your proposal does in case anyone fails to migrate before the deadline. On the other hand, it's equally catastrophic for digital signatures to be broken and funds lost in any scenario. So it seems we are staring down two extremely untenable outcomes, both of which see the fundamental properties of a blockchain shattered in one way or another. I hope it doesn't come down to having to choose one or the other. There is very serious financial harm that will occur in either scenario. I dearly hope there is a practical technological solution that allows for safe and fair migration, and in my mind and experience, I don't think we have to resign ourselves to a zero sum game just yet. But I appreciate your proposal and the proactive nature of this discussion, it's important to have these conversations now rather than later. On Wed, Feb 19, 2025 at 1:50=E2=80=AFPM Agustin Cruz wrote: > Hi Dustin, > > My proposal is not about locking down or confiscating funds. It is about > ensuring that vulnerable pre-P2PKH funds are migrated to quantum-safe > addresses before any quantum adversary can exploit them. Even though P2PK= H > addresses are secured by hashes that are currently considered safe, relyi= ng > solely on that safety may leave us exposed in the future, especially as > quantum capabilities continue to evolve. Without a forced migration, we > risk leaving a significant portion of the coin supply vulnerable. Conside= r > the possibility that if we don=E2=80=99t act, any Bitcoin in lost wallets= could > eventually be hacked and put back into circulation. Such a scenario would > be catastrophic for the network. > > I believe that by enforcing a deadline for migration, we provide rightful > owners with a clear, non-negotiable opportunity to secure their funds. Th= is > approach is not merely hypothetical. It is a proactive measure that > addresses the imminent risk of quantum attacks. While turnstile mechanism= s > have been considered and might have merit under certain conditions, I > remain committed to the idea that a forced migration, with sufficient > notice and robust safeguards, is both realistic and necessary to protect > the long-term security of Bitcoin. > > On Wed, Feb 19, 2025 at 6:35=E2=80=AFPM Dustin Ray > wrote: > >> To be clear, the turnstile approach is definitely a forced migration. It >> just means that instead of permanently confiscating funds and removing t= hem >> from circulation, you force the rightful owners of those funds to move t= hem >> into quantum safe addresses, assuming the existence of a hypothetical >> turnstile mechanism. There's too many hypotheticals with this idea right >> now to give it any more than a cursory glance, but turnstiles have been >> built before and could potentially be built again in this scenario. >> >> For further clarification, I'm suggesting that we enforce migration of >> unspent funds in p2pkh addresses because they are already secured by has= hes >> which are currently conjectured to remain safe against a quantum adversa= ry. >> Pre-p2pkh addresses are probably the most vulnerable but few of these ha= d >> seen use comparatively and may require confiscation. >> >> If your idea is to simply lock down and confiscate any pre-pq safe funds= , >> I resolutely disagree with that decision and I am fairly confident that >> consensus will fail to materialize around that. What I'm suggesting howe= ver >> is that your idea is realistic and sound if we assume the existence of s= ome >> mechanism that allows rightful owners of pre-pq funds the opportunity to= do >> nothing except migrate to safe addresses which then resolves the issue. >> >> On Wed, Feb 19, 2025 at 1:07=E2=80=AFPM Agustin Cruz >> wrote: >> >>> Hi Dustin, >>> >>> I remain convinced that a forced migration mechanism=E2=80=94with a cle= ar block >>> height deadline after which quantum-unsafe funds become unspendable=E2= =80=94is the >>> more robust and secure approach. Here=E2=80=99s why: >>> >>> A forced migration approach is unambiguous. By establishing a definitiv= e >>> deadline, we eliminate the need for an additional transitional transact= ion >>> type, thereby reducing complexity and potential attack vectors. Additio= nal >>> complexity could inadvertently open up new vulnerabilities that a more >>> straightforward deadline avoids. >>> >>> If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost >>> wallets=E2=80=94including coins in addresses that no longer have active= private key >>> management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventua= lly be compromised >>> by quantum adversaries. If these coins were hacked and put back into >>> circulation, the resulting market shock would be catastrophic. The forc= ed >>> migration mechanism is designed to preempt such a scenario by ensuring = that >>> only quantum-safe funds can be spent once the deadline is reached. >>> >>> El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp. m., Dustin Ray < >>> dustinvonsandwich@gmail.com> escribi=C3=B3: >>> >>>> It's worth considering a hypothetical but as of yet unknown middle >>>> ground solution, again nothing like this exists currently but conceptu= ally >>>> it would be interesting to explore: >>>> >>>> 1. At some block height deemed appropriate, modify consensus so that >>>> any pre-quantum unspent funds are restricted from being spent as norma= l. >>>> >>>> 2. Develop a new transaction type whose sole purpose is to migrate >>>> funds from a quantum unsafe address to a safe one. >>>> >>>> 3. This new transaction type is a quantum safe digital signature, but >>>> here's the hypothetical: It is satisfied by developing a mechanism by = which >>>> a private key from a quantum-unsafe scheme can be repurposed as a priv= ate >>>> key for a pq-safe scheme. It may also be possible that since we know t= he >>>> hash of the public key, perhaps we can invent some mechanism whereby a >>>> quantum safe signature is created from an ecdsa private key that direc= tly >>>> implies knowledge of a secret key that derived the known public key. >>>> >>>> In this way, we create a kind of turnstile that can safely transition >>>> funds from unsafe addresses into safe ones. Such turnstiles have been = used >>>> in blockchains before, a notable example is in the zcash network as pa= rt of >>>> an audit of shielded funds. >>>> >>>> There are likely hidden complexities in this idea that may cause it to >>>> be completely unworkable, but a theoretical transition mechanism both >>>> prevents a heavy handed confiscation of funds and also prevents funds = from >>>> being stolen and injected back into the supply under illegitimate pret= enses. >>>> >>>> This only works for p2pkh, anything prior to this is immediately >>>> vulnerable to key inversion, but Satoshi owns most of those coins as f= ar as >>>> we know, so confiscating them might not be as controversial. >>>> >>>> I'm typing this on my phone so sorry for the lack of detailed >>>> references. I think the core idea is clear though. >>>> >>>> On Wed, Feb 19, 2025 at 10:47=E2=80=AFAM Agustin Cruz >>>> wrote: >>>> >>>>> Hi Hunter, >>>>> >>>>> I appreciate the work you=E2=80=99re doing on BIP-360 for Anduro. You= r point >>>>> about not =E2=80=9Cconfiscating=E2=80=9D old coins and allowing those= with quantum >>>>> capabilities to free them up is certainly a valid one, and I understa= nd the >>>>> argument that any inflationary impact could be transitory. >>>>> >>>>> From my viewpoint, allowing quantum-capable adversaries to reintroduc= e >>>>> dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) could = have >>>>> unintended consequences that go beyond transient inflation. It could >>>>> fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disru= pt economic >>>>> assumptions built around the current distribution of coins. While som= e >>>>> might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their = sudden reappearance >>>>> could cause lasting market shocks and undermine confidence. The goal = of a >>>>> proactive migration is to close the door on such a scenario before it >>>>> becomes imminent. >>>>> >>>>> I agree that Q-day won=E2=80=99t necessarily be a single, catastrophi= c moment. >>>>> It will likely be gradual and subtle, giving the network some time to >>>>> adapt. That said, one challenge is ensuring we don=E2=80=99t find our= selves in an >>>>> emergency scramble the moment a capable quantum machine appears. A fo= rced >>>>> or proactive migration is an admittedly strong measure, but it attemp= ts to >>>>> address the scenario where a slow, creeping capability becomes a sudd= en >>>>> attack vector once it matures. In that sense, =E2=80=9Crushing=E2=80= =9D isn=E2=80=99t ideal, but >>>>> neither is waiting until the threat is undeniably present. >>>>> >>>>> El mi=C3=A9, 19 de feb de 2025, 1:31=E2=80=AFp. m., Hunter Beast >>>>> escribi=C3=B3: >>>>> >>>>>> I don't see why old coins should be confiscated. The better option i= s >>>>>> to let those with quantum computers free up old coins. While this mi= ght >>>>>> have an inflationary impact on bitcoin's price, to use a turn of phr= ase, >>>>>> the inflation is transitory. Those with low time preference should s= upport >>>>>> returning lost coins to circulation. >>>>>> >>>>>> Also, I don't see the urgency, considering the majority of coins are >>>>>> in either P2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signature= s >>>>>> aren't added, such as with BIP-360, there will be some concern aroun= d long >>>>>> exposure attacks on P2TR coins. For large amounts, it would be smart= to >>>>>> modify wallets to support broadcasting transactions to private mempo= ol >>>>>> services such as Slipstream, to mitigate short exposure attacks. Tho= se will >>>>>> also be rarer early on since a CRQC capable of a long exposure attac= k is >>>>>> much simpler than one capable of pulling off a short exposure attack >>>>>> against a transaction in the mempool. >>>>>> >>>>>> Bitcoin's Q-day likely won't be sudden and obvious. It will also tak= e >>>>>> time to coordinate a soft fork activation. This shouldn't be rushed. >>>>>> >>>>>> In the interest of transparency, it's worth mentioning that I'm >>>>>> working on a BIP-360 implementation for Anduro. Both Anduro and Slip= stream >>>>>> are MARA services. >>>>>> >>>>>> On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cr= uz wrote: >>>>>> >>>>>>> Hi Dustin: >>>>>>> >>>>>>> I understand that the proposal is an extraordinary ask=E2=80=94it w= ould >>>>>>> indeed void a non-trivial part of the coin supply if users do not m= igrate >>>>>>> in time, and under normal circumstances, many would argue that unus= ed P2PKH >>>>>>> funds are safe from a quantum adversary. However, the intent here i= s to be >>>>>>> proactive rather than reactive. >>>>>>> >>>>>>> The concern isn=E2=80=99t solely about funds in active wallets. Con= sider >>>>>>> that if we don=E2=80=99t implement a proactive migration, any Bitco= in in lost >>>>>>> wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99s if he = is not alive=E2=80=94will remain >>>>>>> vulnerable. In the event of a quantum breakthrough, those coins cou= ld be >>>>>>> hacked and put back into circulation. Such an outcome would not onl= y >>>>>>> disrupt the balance of supply but could also undermine the trust an= d >>>>>>> security that Bitcoin has built over decades. In short, the consequ= ences of >>>>>>> a reactive measure in a quantum emergency could be far more catastr= ophic. >>>>>>> >>>>>>> While I agree that a forced migration during an active quantum >>>>>>> attack scenario might be more acceptable (since funds would likely = be >>>>>>> considered lost anyway), waiting until such an emergency arises lea= ves us >>>>>>> with little margin for error. By enforcing a migration now, we crea= te a >>>>>>> window for the entire community to transition safely=E2=80=94assumi= ng we set the >>>>>>> deadline generously and provide ample notifications, auto-migration= tools, >>>>>>> and, if necessary, emergency extensions. >>>>>>> >>>>>>> El mar, 11 de feb de 2025, 9:48=E2=80=AFp. m., Dustin Ray < >>>>>>> dustinvo...@gmail.com> escribi=C3=B3: >>>>>>> >>>>>>>> I think youre going to have a tough time getting consensus on this >>>>>>>> proposal. It is an extraordinary ask of the community to instill a >>>>>>>> change that will essentially void out a non-trivial part of the co= in >>>>>>>> supply, especially when funds behind unused P2PKH addresses are at >>>>>>>> this point considered safe from a quantum adversary. >>>>>>>> >>>>>>>> In my opinion, where parts of this proposal make sense is in a >>>>>>>> quantum >>>>>>>> emergency in which an adversary is actively extracting private key= s >>>>>>>> from known public keys and a transition must be made quickly and >>>>>>>> decisively. In that case, we might as well consider funds to be lo= st >>>>>>>> anyways. In any other scenario prior to this hypothetical emergenc= y >>>>>>>> however, I have serious doubts that the community is going to >>>>>>>> consent >>>>>>>> to this proposal as it stands. >>>>>>>> >>>>>>>> On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Hi Dustin >>>>>>>> > >>>>>>>> > To clarify, the intent behind making legacy funds unspendable >>>>>>>> after a certain block height is indeed a hard security measure=E2= =80=94designed to >>>>>>>> mitigate the potentially catastrophic risk posed by quantum attack= s on >>>>>>>> ECDSA. The idea is to force a proactive migration of funds to >>>>>>>> quantum-resistant addresses before quantum computers become capabl= e of >>>>>>>> compromising the current cryptography. >>>>>>>> > >>>>>>>> > The migration window is intended to be sufficiently long >>>>>>>> (determined by both block height and community input) to provide a= mple time >>>>>>>> for users and service providers to transition. >>>>>>>> > >>>>>>>> > >>>>>>>> > El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray < >>>>>>>> dustinvo...@gmail.com> escribi=C3=B3: >>>>>>>> >> >>>>>>>> >> Right off the bat I notice you are proposing that legacy funds >>>>>>>> become unspendable after a certain block height which immediately = raises >>>>>>>> serious problems. A migration to quantum hard addresses in this ma= nner >>>>>>>> would cause serious financial damage to anyone holding legacy fund= s, if I >>>>>>>> understand your proposal correctly. >>>>>>>> >> >>>>>>>> >> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz < >>>>>>>> agusti...@gmail.com> wrote: >>>>>>>> >>> >>>>>>>> >>> Dear Bitcoin Developers, >>>>>>>> >>> >>>>>>>> >>> I am writing to share my proposal for a new Bitcoin Improvemen= t >>>>>>>> Proposal (BIP) titled Quantum-Resistant Address Migration Protocol= (QRAMP). >>>>>>>> The goal of this proposal is to safeguard Bitcoin against potentia= l future >>>>>>>> quantum attacks by enforcing a mandatory migration period for fund= s held in >>>>>>>> legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant a= ddresses. >>>>>>>> >>> >>>>>>>> >>> The proposal outlines: >>>>>>>> >>> >>>>>>>> >>> Reducing Vulnerabilities: Transitioning funds to >>>>>>>> quantum-resistant schemes preemptively to eliminate the risk posed= by >>>>>>>> quantum attacks on exposed public keys. >>>>>>>> >>> Enforcing Timelines: A hard migration deadline that forces >>>>>>>> timely action, rather than relying on a gradual, voluntary migrati= on that >>>>>>>> might leave many users at risk. >>>>>>>> >>> Balancing Risks: Weighing the non-trivial risk of funds being >>>>>>>> permanently locked against the potential catastrophic impact of a = quantum >>>>>>>> attack on Bitcoin=E2=80=99s security. >>>>>>>> >>> >>>>>>>> >>> Additionally, the proposal addresses common criticisms such as >>>>>>>> the risk of permanent fund loss, uncertain quantum timelines, and = the >>>>>>>> potential for chain splits. It also details backwards compatibilit= y >>>>>>>> measures, comprehensive security considerations, an extensive suit= e of test >>>>>>>> cases, and a reference implementation plan that includes script in= terpreter >>>>>>>> changes, wallet software updates, and network monitoring tools. >>>>>>>> >>> >>>>>>>> >>> For your convenience, I have published the full proposal on my >>>>>>>> GitHub repository. You can review it at the following link: >>>>>>>> >>> >>>>>>>> >>> Quantum-Resistant Address Migration Protocol (QRAMP) Proposal >>>>>>>> on GitHub >>>>>>>> >>> >>>>>>>> >>> I welcome your feedback and suggestions and look forward to >>>>>>>> engaging in a constructive discussion on how best to enhance the s= ecurity >>>>>>>> and resilience of the Bitcoin network in the quantum computing era= . >>>>>>>> >>> >>>>>>>> >>> Thank you for your time and consideration. >>>>>>>> >>> >>>>>>>> >>> Best regards, >>>>>>>> >>> >>>>>>>> >>> Agustin Cruz >>>>>>>> >>> >>>>>>>> >>> -- >>>>>>>> >>> 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+...@googlegroups.com. >>>>>>>> >>> To view this discussion visit >>>>>>>> https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-83= 03-8c5bde8598e7n%40googlegroups.com >>>>>>>> . >>>>>>> >>>>>>> >>>>>>>> -- >>>>>> 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/f9e233e0-9d87-4e71-9a9f= -3310ea242194n%40googlegroups.com >>>>>> >>>>>> . >>>>>> >>>>> -- >>>>> 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, sen= d >>>>> an email to bitcoindev+unsubscribe@googlegroups.com. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5t= mfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.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/= CAC3UE4KaVVjLGsAvACmh75KkCNZeHJNnk2%2BFuZOu23YFAyYg5w%40mail.gmail.com. --0000000000004ee7c4062e85f653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't disagree personally with most of what you'= ;re saying except where the real catastrophe lies. Id argue it's catast= rophic for the value proposition of a blockchain to effectively seize funds= , which is what your proposal does in case anyone fails to migrate before t= he deadline.

On the othe= r hand, it's equally catastrophic for digital signatures to be broken a= nd funds lost in any scenario. So it seems we are staring down two extremel= y untenable outcomes, both of which see the fundamental properties of a blo= ckchain shattered in one way or another.

<= div dir=3D"auto">I hope it doesn't come down to having to choose one or= the other. There is very serious financial harm that will occur in either = scenario. I dearly hope there is a practical technological solution that al= lows for safe and fair migration, and in my mind and experience, I don'= t think we have to resign ourselves to a zero sum game just yet. But I appr= eciate your proposal and the proactive nature of this discussion, it's = important to have these conversations now rather than later.

=
On Wed, Feb 19, 2025 at 1:50=E2=80=AFPM Agustin Cruz <agustin.cruz@gmail.com> wrote:
Hi Dustin,

My propo= sal is not about locking down or confiscating funds. It is about ensuring t= hat vulnerable pre-P2PKH funds are migrated to quantum-safe addresses befor= e any quantum adversary can exploit them. Even though P2PKH addresses are s= ecured by hashes that are currently considered safe, relying solely on that= safety may leave us exposed in the future, especially as quantum capabilit= ies continue to evolve. Without a forced migration, we risk leaving a signi= ficant portion of the coin supply vulnerable. Consider the possibility that= if we don=E2=80=99t act, any Bitcoin in lost wallets could eventually be h= acked and put back into circulation. Such a scenario would be catastrophic = for the network.

I believe that by enforcing a deadline for migratio= n, we provide rightful owners with a clear, non-negotiable opportunity to s= ecure their funds. This approach is not merely hypothetical. It is a proact= ive measure that addresses the imminent risk of quantum attacks. While turn= stile mechanisms have been considered and might have merit under certain co= nditions, I remain committed to the idea that a forced migration, with suff= icient notice and robust safeguards, is both realistic and necessary to pro= tect the long-term security of Bitcoin.

On Wed, Feb 19, 2025 at 6:35=E2= =80=AFPM Dustin Ray <dustinvonsandwich@gmail.com> wrote:
To be clear, the turnstile a= pproach is definitely a forced migration. It just means that instead of per= manently confiscating funds and removing them from circulation, you force t= he rightful owners of those funds to move them into quantum safe addresses,= assuming the existence of a hypothetical turnstile mechanism. There's = too many hypotheticals with this idea right now to give it any more than a = cursory glance, but turnstiles have been built before and could potentially= be built again in this scenario.

For further clarification, I'm suggesting that we e= nforce migration of unspent funds in p2pkh addresses because they are alrea= dy secured by hashes which are currently conjectured to remain safe against= a quantum adversary. Pre-p2pkh addresses are probably the most vulnerable = but few of these had seen use comparatively and may require confiscation.

If your idea is= to simply lock down and confiscate any pre-pq safe funds, I resolutely dis= agree with that decision and I am fairly confident that consensus will fail= to materialize around that. What I'm suggesting however is that your i= dea is realistic and sound if we assume the existence of some mechanism tha= t allows rightful owners of pre-pq funds the opportunity to do nothing exce= pt migrate to safe addresses which then resolves the issue.

On Wed, Feb 19, 2025 at 1:07=E2=80=AFPM Agustin C= ruz <agustin= .cruz@gmail.com> wrote:
=

Hi Dustin,

I remain convinced that a force= d migration mechanism=E2=80=94with a clear block height deadline after whic= h quantum-unsafe funds become unspendable=E2=80=94is the more robust and se= cure approach. Here=E2=80=99s why:

A forced migration approach is unambiguous. By establishing a definitive de= adline, we eliminate the need for an additional transitional transaction ty= pe, thereby reducing complexity and potential attack vectors. Additional co= mplexity could inadvertently open up new vulnerabilities that a more straig= htforward deadline avoids.

If we don=E2=80=99t enforce a hard migration, any Bitcoin in lost wallets= =E2=80=94including coins in addresses that no longer have active private ke= y management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventuall= y be compromised by quantum adversaries. If these coins were hacked and put= back into circulation, the resulting market shock would be catastrophic. T= he forced migration mechanism is designed to preempt such a scenario by ens= uring that only quantum-safe funds can be spent once the deadline is reache= d.


El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp.=C2=A0m., Dustin Ray &= lt;dustinv= onsandwich@gmail.com> escribi=C3=B3:
It's worth considering a hypothetical but as of yet unknow= n middle ground solution, again nothing like this exists currently but conc= eptually it would be interesting to explore:

1. At some block height deemed appropriate, modify con= sensus so that any pre-quantum unspent funds are restricted from being spen= t as normal.

2. Develop = a new transaction type whose sole purpose is to migrate funds from a quantu= m unsafe address to a safe one.

3. This new transaction type is a quantum safe digital signature,= but here's the hypothetical: It is satisfied by developing a mechanism= by which a private key from a quantum-unsafe scheme can be repurposed as a= private key for a pq-safe scheme. It may also be possible that since we kn= ow the hash of the public key, perhaps we can invent some mechanism whereby= a quantum safe signature is created from an ecdsa private key that directl= y implies knowledge of a secret key that derived the known public key.

In this way, we create a kin= d of turnstile that can safely transition funds from unsafe addresses into = safe ones. Such turnstiles have been used in blockchains before, a notable = example is in the zcash network as part of an audit of shielded funds.=C2= =A0

There are likely hid= den complexities in this idea that may cause it to be completely unworkable= , but a theoretical transition mechanism both prevents a heavy handed confi= scation of funds and also prevents funds from being stolen and injected bac= k into the supply under illegitimate pretenses.

=
This only works for p2pkh, anything prior to this i= s immediately vulnerable to key inversion, but Satoshi owns most of those c= oins as far as we know, so confiscating them might not be as controversial.=

I'm typing this on = my phone so sorry for the lack of detailed references. I think the core ide= a is clear though.

On Wed, Feb 19, 2025 at 10:47=E2=80=AFAM Agustin Cru= z <agustin.cruz@gmail.com> wrote:

Hi Hunter,

I appreciate= the work you=E2=80=99re doing on BIP-360 for Anduro. Your point about not = =E2=80=9Cconfiscating=E2=80=9D old coins and allowing those with quantum ca= pabilities to free them up is certainly a valid one, and I understand the a= rgument that any inflationary impact could be transitory.

From my viewpoint, allowing quantum-capable adversaries to r= eintroduce dormant coins (e.g., Satoshi=E2=80=99s if those keys are lost) c= ould have unintended consequences that go beyond transient inflation. It co= uld fundamentally alter trust in Bitcoin=E2=80=99s fixed supply and disrupt= economic assumptions built around the current distribution of coins. While= some might view these dormant coins as =E2=80=9Cfair game,=E2=80=9D their = sudden reappearance could cause lasting market shocks and undermine confide= nce. The goal of a proactive migration is to close the door on such a scena= rio before it becomes imminent.

I agree that Q-day won=E2= =80=99t necessarily be a single, catastrophic moment. It will likely be gra= dual and subtle, giving the network some time to adapt. That said, one chal= lenge is ensuring we don=E2=80=99t find ourselves in an emergency scramble = the moment a capable quantum machine appears. A forced or proactive migrati= on is an admittedly strong measure, but it attempts to address the scenario= where a slow, creeping capability becomes a sudden attack vector once it m= atures. In that sense, =E2=80=9Crushing=E2=80=9D isn=E2=80=99t ideal, but n= either is waiting until the threat is undeniably present.


El mi=C3=A9, 1= 9 de feb de 2025, 1:31=E2=80=AFp.=C2=A0m., Hunter Beast <hunter@surmount= .systems> escribi=C3=B3:
I don't see why o= ld coins should be confiscated. The better option is to let those with quan= tum computers free up old coins. While this might have an inflationary impa= ct on bitcoin's price, to use a turn of phrase, the inflation is transi= tory. Those with low time preference should support returning lost coins to= circulation.

Also, I don't see the urgency, conside= ring the majority of coins are in either P2PKH, P2WPKH, P2SH, and P2WSH add= resses. If PQC signatures aren't added, such as with BIP-360, there wil= l be some concern around long exposure attacks on P2TR coins. For large amo= unts, it would be smart to modify wallets to support broadcasting transacti= ons to private mempool services such as Slipstream, to mitigate short expos= ure attacks. Those will also be rarer early on since a CRQC capable of a lo= ng exposure attack is much simpler than one capable of pulling off a short = exposure attack against a transaction in the mempool.

<= div>Bitcoin's Q-day likely won't be sudden and obvious. It will als= o take time to coordinate a soft fork activation. This shouldn't be rus= hed.

In the interest of transparency, it's wor= th mentioning that I'm working on a BIP-360 implementation for Anduro. = Both Anduro and Slipstream are MARA services.

On Tuesday, Februa= ry 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz wrote:

Hi Dustin:

I understand that the proposal is an extraordinary ask=E2=80= =94it would indeed void a non-trivial part of the coin supply if users do n= ot migrate in time, and under normal circumstances, many would argue that u= nused P2PKH funds are safe from a quantum adversary. However, the intent he= re is to be proactive rather than reactive.

The concern isn=E2=80=99t solely about funds in active walle= ts. Consider that if we don=E2=80=99t implement a proactive migration, any = Bitcoin in lost wallets=E2=80=94including, hypothetically, Satoshi=E2=80=99= s if he is not alive=E2=80=94will remain vulnerable. In the event of a quan= tum breakthrough, those coins could be hacked and put back into circulation= . Such an outcome would not only disrupt the balance of supply but could al= so undermine the trust and security that Bitcoin has built over decades. In= short, the consequences of a reactive measure in a quantum emergency could= be far more catastrophic.

While I agree that a forced migration during an active quant= um attack scenario might be more acceptable (since funds would likely be co= nsidered lost anyway), waiting until such an emergency arises leaves us wit= h little margin for error. By enforcing a migration now, we create a window= for the entire community to transition safely=E2=80=94assuming we set the = deadline generously and provide ample notifications, auto-migration tools, = and, if necessary, emergency extensions.


El mar, 11 de feb de 2025, 9:48= =E2=80=AFp.=C2=A0m., Dustin Ray <dustinvo...@gmail.com> escribi=C3=B3:
= I think youre going to have a tough time getting consensus on this
proposal. It is an extraordinary ask of the community to instill a
change that will essentially void out a non-trivial part of the coin
supply, especially when funds behind unused P2PKH addresses are at
this point considered safe from a quantum adversary.

In my opinion, where parts of this proposal make sense is in a quantum
emergency in which an adversary is actively extracting private keys
from known public keys and a transition must be made quickly and
decisively. In that case, we might as well consider funds to be lost
anyways. In any other scenario prior to this hypothetical emergency
however, I have serious doubts that the community is going to consent
to this proposal as it stands.

On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz <agusti...@gmail.com> wrote:
>
> Hi Dustin
>
> To clarify, the intent behind making legacy funds unspendable after a = certain block height is indeed a hard security measure=E2=80=94designed to = mitigate the potentially catastrophic risk posed by quantum attacks on ECDS= A. The idea is to force a proactive migration of funds to quantum-resistant= addresses before quantum computers become capable of compromising the curr= ent cryptography.
>
> The migration window is intended to be sufficiently long (determined b= y both block height and community input) to provide ample time for users an= d service providers to transition.
>
>
> El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray <dustinvo...@gmail.com>= ; escribi=C3=B3:
>>
>> Right off the bat I notice you are proposing that legacy funds bec= ome unspendable after a certain block height which immediately raises serio= us problems. A migration to quantum hard addresses in this manner would cau= se serious financial damage to anyone holding legacy funds, if I understand= your proposal correctly.
>>
>> On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz <agusti...@gmail.com> wro= te:
>>>
>>> Dear Bitcoin Developers,
>>>
>>> I am writing to share my proposal for a new Bitcoin Improvemen= t Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (QRAMP= ). The goal of this proposal is to safeguard Bitcoin against potential futu= re quantum attacks by enforcing a mandatory migration period for funds held= in legacy Bitcoin addresses (secured by ECDSA) to quantum-resistant addres= ses.
>>>
>>> The proposal outlines:
>>>
>>> Reducing Vulnerabilities: Transitioning funds to quantum-resis= tant schemes preemptively to eliminate the risk posed by quantum attacks on= exposed public keys.
>>> Enforcing Timelines: A hard migration deadline that forces tim= ely action, rather than relying on a gradual, voluntary migration that migh= t leave many users at risk.
>>> Balancing Risks: Weighing the non-trivial risk of funds being = permanently locked against the potential catastrophic impact of a quantum a= ttack on Bitcoin=E2=80=99s security.
>>>
>>> Additionally, the proposal addresses common criticisms such as= the risk of permanent fund loss, uncertain quantum timelines, and the pote= ntial for chain splits. It also details backwards compatibility measures, c= omprehensive security considerations, an extensive suite of test cases, and= a reference implementation plan that includes script interpreter changes, = wallet software updates, and network monitoring tools.
>>>
>>> For your convenience, I have published the full proposal on my= GitHub repository. You can review it at the following link:
>>>
>>> Quantum-Resistant Address Migration Protocol (QRAMP) Proposal = on GitHub
>>>
>>> I welcome your feedback and suggestions and look forward to en= gaging in a constructive discussion on how best to enhance the security and= resilience of the Bitcoin network in the quantum computing era.
>>>
>>> Thank you for your time and consideration.
>>>
>>> Best regards,
>>>
>>> Agustin Cruz
>>>
>>> --
>>> You received this message because you are subscribed to the Go= ogle Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from = it, send an email to b= itcoindev+...@googlegroups.com.
>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/08a544fa-a29b-45c2= -8303-8c5bde8598e7n%40googlegroups.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 bitcoindev+unsubscribe@googlegroups= .com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71= -9a9f-3310ea242194n%40googlegroups.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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGL= E0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.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/CAC3UE4KaVVjLGsAvACmh75KkCNZeHJNnk2%2BFuZOu23YFAyYg5w%40ma= il.gmail.com.
--0000000000004ee7c4062e85f653--