path: root/47/5803e492e490daaef1c1cd9e05f03bbdbbcfef

Delivery-date: Sat, 08 Mar 2025 16:22:30 -0800
Received: from mail-qk1-f183.google.com ([209.85.222.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCQ6XM4A6IDBBOV6WO7AMGQEIGHPNAI@googlegroups.com>)
	id 1tr4R1-0007Lq-Gq
	for bitcoindev@gnusha.org; Sat, 08 Mar 2025 16:22:30 -0800
Received: by mail-qk1-f183.google.com with SMTP id af79cd13be357-7c546efca59sf172708685a.1
        for <bitcoindev@gnusha.org>; Sat, 08 Mar 2025 16:22:27 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1741479741; cv=pass;
        d=google.com; s=arc-20240605;
        b=hYLEfwDVWcl1LjyTJLWYSB1SFmd/lfwCMtsIwttOcJBufI7RHbpK/6SZAqWcscehqn
         c8oBQfxQUCogyG0l+aqHEB76gomNa24W4+/Z2FAv/mz80yEi7LARiLfLGmjGwDnREdbv
         KP0f8bYgZkwU7zfBl3mY78k+6CjGS8/VJf2lXW3wt1v1mcpdmeolE2X/Vyp5bl09UQTV
         DxF6HkMi6yoEm/pVmyjWJckhP80BV15werjPT1gcPenD1o5iH2YcjQtPVLjaYvfwwVPN
         7Juc/T7sMSaHnZmBxOeygGJuobMIENdl5PKw0SoE4tDJAhPwgTJKmBFo1nYbzRVpOW0F
         o8zA==
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:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=ICiy9P++LzH4ph8Cer4zgoI/DU+Ks8QERV5Of0MU0D4=;
        fh=IPktEptM+RifB8WhK/zeTMKwYGGPUwxJ6h93vf/yUnk=;
        b=jO1T1LOO4O/AnRpiaBSvQ1FGvU+0nOrnOqkYHj3hUGj/ofTM1QxsfkNS37gKEgoauh
         mVKhHkDv2AZ4XfzksdwXxc1o4R7kapPmeVfNV7l4oi/SisD+pvg7R7mRQ3rtYqkKfLrx
         p99Yq4v00ovYE/JVQKBB2P15TTkmw0Jz5c+G1CXbzEjHtxugNMCpO7kikK9KBgkAPkzL
         A2NTNrOKeAZ0Lcuhi4vrAgnElugvTlEo6vT29WaVeT1PqSPoB8mBKemBF0wi7eyVnKAm
         kCf3QW77coA4Bfevqp1hWeD5oN3xUi5ze8TWDRti/gi0Aviwzkfp8Q1MSOhazTwEGKRr
         FIKw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ez3L7wy8;
       spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=agustin.cruz@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=1741479741; x=1742084541; 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:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ICiy9P++LzH4ph8Cer4zgoI/DU+Ks8QERV5Of0MU0D4=;
        b=kvEDyX69Oi6bDiSg0y0qzqdE64uiARIZnsYThLEglrdQ8heGE1A9HB/HuTAmfUEB8P
         BM42vo8Nl0UdeJV16Ir6iwyAYcGAkv8ZiWSl6dlBqzbuCg7oeTcKePI81nX5zXWl1p+m
         q9OzEU+1353L2XI1d3pmLnOMp66AgKeJtDLM6aIerBe3dpy4rs7Az+XCT/aeXV7KqtsM
         s0bncrL5FmMtPJkqDPs2+VgitwGTadLV3Fl27jXH+VBvxYB9NiqC4TixGqaBIyK/VVRn
         DrlcUO31ylmUSSaFTJvx2DIkmfrEyTmVk88dU/P6xZyUeVPmPmPVFoxEuzGbBZnOwXEO
         YpiQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741479741; x=1742084541; 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:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=ICiy9P++LzH4ph8Cer4zgoI/DU+Ks8QERV5Of0MU0D4=;
        b=OkwuSNkfprLb3wJ+SNoaNnp1Nn+5HjUOTXqF8vguWeTSAMMpgkRq7wxYYfGwMCrHqV
         yj6aAf/gdYh15h7lEtRuBYmBWABsGkQMl1x8eHZ6ccz72Oy9LmgByUOS0EF14ZbIzhWr
         Z7zJWmHD4xbcIXLI0ZqRW3QYpYRxtOpgd2G0V3g+lGaCNxLE90rfLWSGi+7vQAE4GAB5
         pXlDX+OnUGPpxQKEHoaFdyhNCCyIywpuaFRGkZNisKnJcyKfef7eDIyq1DVeCAhJ/MZu
         E265w3kKVSvJmuLGuZSThcBfxI0ILq0CIupw8Oc8aZSeoM7PeV6OuqSfoxfHGouINKMQ
         qKgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741479741; x=1742084541;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender: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=ICiy9P++LzH4ph8Cer4zgoI/DU+Ks8QERV5Of0MU0D4=;
        b=SKIUeH8r1HEG3APFnnZ3ksKTUxer1LIML5O5L7haELwj0NZUsPcHlq8Z5uvfZ7Qnj8
         i+Yks0YuVL+xytCZgk1xnOmB+Jtt5YJnOIR5yEiyS36ryJ0KQKcBXaXzG0IU34GkCe+u
         skaOzN3o9a/x1p8kDbdLFkiAec7OzsA2JlHHI4q1xCa08Gm3j4gL8ZIBquC6VA/RlJFV
         yV9rrS/4Jw/3j8tSqlhDl++skvR5XpKo0rr1bMOh3565Zm8FA5U3g+tFFSA05upuQcQe
         pqmJW+/iQ6+H+4Uo1fqHT1Q06E9GR39RWssM5xHjHd7B4ZVpE1WrxsdU2KZ9hENwvvoj
         6yCg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCX3DZImZ6yctq95Ic4IS4kbxfTQnYNFrKbCi30g9+hgZv1XngovYn6B0volu5Y5gMmySIyq5j8FJyZP@gnusha.org
X-Gm-Message-State: AOJu0YziRQUt4adTYaMQPEBrBY9c3vm+TcDJMX7Ympj9K7qoFdgAAXyZ
	Fw0eq54zhMYuflTU7r+wXi1/ZTtRsndRclm+uT9dRgvnMuojPt7e
X-Google-Smtp-Source: AGHT+IGyYw7dDlpWESN51zT6nHL2ZM5BfT3tEbI789IUAg46G4/6AIsLCR2smqTBjKoFsKQ+OCYDOg==
X-Received: by 2002:a05:620a:63c4:b0:7c3:d79c:9c3b with SMTP id af79cd13be357-7c4e167798dmr1478858985a.5.1741479741264;
        Sat, 08 Mar 2025 16:22:21 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVH/DTV75daWai3MRPlsI+fWl5UMJvaKqo0bA4T0JAaqYg==
Received: by 2002:ac8:6614:0:b0:476:7e35:1cd5 with SMTP id d75a77b69052e-4767e352182ls2376641cf.0.-pod-prod-04-us;
 Sat, 08 Mar 2025 16:22:18 -0800 (PST)
X-Received: by 2002:a05:620a:2722:b0:7c3:c869:1aff with SMTP id af79cd13be357-7c4e168857cmr1115380685a.16.1741479738412;
        Sat, 08 Mar 2025 16:22:18 -0800 (PST)
Received: by 2002:a05:600c:6dcc:b0:43b:c69d:7156 with SMTP id 5b1f17b1804b1-43bd1ae1deems5e9;
        Fri, 7 Mar 2025 10:43:23 -0800 (PST)
X-Received: by 2002:a05:600c:3501:b0:439:608b:c4ad with SMTP id 5b1f17b1804b1-43c601cf23fmr30987555e9.3.1741373000986;
        Fri, 07 Mar 2025 10:43:20 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1741373000; cv=none;
        d=google.com; s=arc-20240605;
        b=hrA9PKshyp04xUYi9Viw9iu6Ifte/MYRCV1PjrVRNu3lgBzVVE9G76nJv6B6QG7OdJ
         RaWUaq2+W1RP2GPIAXBwhD9oLN9fJoyODQ04mMVraTUQsBRbQKkPNDhydTkWkUgzeYlm
         lEjPDEwZbE840d1DvwhcNslQ08OxyAyBj3fygO5FoDeCGvIrij9x9sjHPt6ge6lKICir
         Erwsmtjor4wvi/K+KnfBSP7qMNIyH0iP1Ue/TJqVxPVSF0BZVmUTLnC5H8xDaVyK24Sf
         ZZCAbAgWITP0FSHx50XsQ2blUZbJkKQI5MqE4BeT7ZnmAjJpD6KPpMp3uJCVuA0rw2yi
         tXbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :dkim-signature;
        bh=2CeNbkg0cVvfwHMtnzlWYs0XVrfIIXf4nbVoh7H0f94=;
        fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=;
        b=iN/cBy+RL8Az75QsNyz2dWst0dMMPNg1aTnI7/v/Ot8DkJJzcrWWQyKUX9HfZpCCZs
         kOtMCw5oXj40RPbMNLiyixUQce2kI2cUqp5B5OKAJoxYtr82YpbbdlaGZQqGNjGkrcFt
         zn+qrRpYUabWd/1ViTDqkO54+5uID0CNTyChzQMtofEdpt80T+n1b34YKnJHs7jX3W2E
         V3KWpnceGrdDoDckxwxKRmfZEIkV6AduiEMFxBPljwV0N1+21J8ZdUZbCCd3+x2Tkbs+
         aJKpS6edLYTyKgngrMGUXHAMbjigc//FsrTrdB+3ijYrK5e0KqUJJ8MV82Xd2ShDLed7
         NEzA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ez3L7wy8;
       spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com. [2a00:1450:4864:20::233])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-43bcbccb2d2si4178395e9.0.2025.03.07.10.43.20
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 07 Mar 2025 10:43:20 -0800 (PST)
Received-SPF: pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) client-ip=2a00:1450:4864:20::233;
Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-30bf8632052so7936411fa.0
        for <bitcoindev@googlegroups.com>; Fri, 07 Mar 2025 10:43:20 -0800 (PST)
X-Gm-Gg: ASbGncspE7UIOBXOE6szLHoIegqnsSkkB7OKnDu1W64LOKAS1/o5GstCKhLwBSjD07u
	PwXwWqDaWGsqmoivshfeZAi0jHXNWO9U3nuQUKo30j17/d27AwClQAl2dy0lRbMQlM2bh+zpfzu
	V6v/ejRe2EbZViAhDUISzlyZvQeA==
X-Received: by 2002:a05:651c:548:b0:30b:f0a2:3e93 with SMTP id
 38308e7fff4ca-30bf45ebeaemr17210761fa.26.1741372999391; Fri, 07 Mar 2025
 10:43:19 -0800 (PST)
MIME-Version: 1.0
References: <08a544fa-a29b-45c2-8303-8c5bde8598e7n@googlegroups.com>
 <CAC3UE4+kme2N6D_Xx8+VaH1BJnkVEfntPmnLQzaqTQfK4D5QhQ@mail.gmail.com>
 <CAJDmzYxJzFs=myecyMS6iJwSni1sDwUVq3kMnNGg=dK5kULRJg@mail.gmail.com>
 <CAC3UE4K=T8BmOeLW9s=x+TBauK+M5Z3MaSicD42+rOj_jZ2Ugw@mail.gmail.com>
 <CAJDmzYzUAzoCj3da-3M_ast0_+Qxf3_J1OXWf88B2D-R70pPrg@mail.gmail.com>
 <f9e233e0-9d87-4e71-9a9f-3310ea242194n@googlegroups.com> <CAJDmzYz=52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg@mail.gmail.com>
 <CAC3UE4K4L58Oz147m5Tnd2cqt7uCN2niyGK6ffRTuu5x5YvRDQ@mail.gmail.com>
 <CAJDmzYzvYkm8At6yMrn+mAXnXbk=-R36SL5WneaDT9-Y-d=11w@mail.gmail.com>
 <CAC3UE4KZ7GajyaPT1DYfjyxAACnntqfAnoxZwc0kNV2yivDnyQ@mail.gmail.com>
 <CAJDmzYzPGz9Xd=kdaGkkL+r1zh5y1cBHNh7SQXJEzg7YUX--PA@mail.gmail.com>
 <CAC3UE4KaVVjLGsAvACmh75KkCNZeHJNnk2+FuZOu23YFAyYg5w@mail.gmail.com> <CAJDmzYyF1g+gfeM4+YJgQxMw-cr6Ktx_q7LgptbNxpyAuV6wEg@mail.gmail.com>
In-Reply-To: <CAJDmzYyF1g+gfeM4+YJgQxMw-cr6Ktx_q7LgptbNxpyAuV6wEg@mail.gmail.com>
From: Agustin Cruz <agustin.cruz@gmail.com>
Date: Fri, 7 Mar 2025 15:42:46 -0300
X-Gm-Features: AQ5f1JpVmvALnQ093rutnF6j0CVqQo3Q9Tyyn0ZSFY9iWwuQGCnYW1no3X2Cs30
Message-ID: <CAJDmzYznDYi8GgmDof_6sJ=kJ1SZUMo-gAo9rgnrthi_p7ur_w@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal for Quantum-Resistant Address Migration
 Protocol (QRAMP) BIP
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000000ce57b062fc4ff47"
X-Original-Sender: agustin.cruz@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=ez3L7wy8;       spf=pass
 (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::233
 as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

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

Hi everyone,

I wanted to kick off a discussion on how the Quantum-Resistant Address
Migration Protocol (QRAMP), could integrate smoothly with the existing
BIP-360 (Pay to Quantum Resistant Hash) proposal. Both of these proposals
aim to protect Bitcoin from potential quantum computing threats, but they
approach the problem from slightly different angles. I believe they could
complement each other nicely.

The QRAMP proposal introduces a mandatory migration period after which
spending from legacy ECDSA-based addresses becomes invalid. The goal is to
push users proactively towards quantum-resistant addresses, ensuring older,
potentially vulnerable public keys are phased out before quantum computing
poses a real threat.

Meanwhile, BIP-360 defines a new quantum-resistant address format and
associated transaction validation rules. It introduces hash-based and
hybrid post-quantum signatures, designed specifically to integrate smoothly
with Bitcoin=E2=80=99s current infrastructure, avoiding sudden disruptions =
or
significantly increased block sizes.

Together, I see QRAMP and BIP-360 forming a robust approach. QRAMP provides
a clear timeline and incentive for users to migrate their funds, while
BIP-360 provides the technical standard and address types to which users
can securely transition. Wallets and infrastructure could offer clear user
guidance throughout the transition period, supporting both legacy and
quantum-resistant addresses simultaneously. Once QRAMP's deadline passes,
the network smoothly moves forward with only quantum-resistant addresses
being valid.

I think this combined approach could provide a secure, user-friendly
transition path, reducing the potential disruption to the network while
effectively mitigating quantum risks. I'd really appreciate your thoughts,
concerns, or ideas on how we could refine this integration.

Regards,

Agust=C3=ADn Cruz

El mi=C3=A9, 19 de feb de 2025, 7:05=E2=80=AFp. m., Dustin Ray <
dustinvonsandwich@gmail.com> escribi=C3=B3:

> 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 you=
r
> 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 tw=
o
> extremely untenable outcomes, both of which see the fundamental propertie=
s
> 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 i=
s
> 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 <agustin.cruz@gmail.=
com>
> 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 P2P=
KH
>> addresses are secured by hashes that are currently considered safe, rely=
ing
>> 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. Consid=
er
>> the possibility that if we don=E2=80=99t act, any Bitcoin in lost wallet=
s could
>> eventually be hacked and put back into circulation. Such a scenario woul=
d
>> be catastrophic for the network.
>>
>> I believe that by enforcing a deadline for migration, we provide rightfu=
l
>> owners with a clear, non-negotiable opportunity to secure their funds. T=
his
>> approach is not merely hypothetical. It is a proactive measure that
>> addresses the imminent risk of quantum attacks. While turnstile mechanis=
ms
>> 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 <dustinvonsandwich@gm=
ail.com>
>> wrote:
>>
>>> To be clear, the turnstile approach is definitely a forced migration. I=
t
>>> just means that instead of permanently confiscating funds and removing =
them
>>> from circulation, you force the 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 righ=
t
>>> 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 ha=
shes
>>> which are currently conjectured to remain safe against a quantum advers=
ary.
>>> Pre-p2pkh addresses are probably the most vulnerable but few of these h=
ad
>>> 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 confide=
nt
>>> that consensus will fail to materialize around that. What I'm suggestin=
g
>>> however is that your idea is realistic and sound if we assume the exist=
ence
>>> of some 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 <agustin.cruz@gmai=
l.com>
>>> wrote:
>>>
>>>> Hi Dustin,
>>>>
>>>> I remain convinced that a forced migration mechanism=E2=80=94with a cl=
ear 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
>>>> definitive deadline, we eliminate the need for an additional transitio=
nal
>>>> transaction type, thereby reducing complexity and potential attack vec=
tors.
>>>> Additional 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 activ=
e private key
>>>> management, such as potentially Satoshi=E2=80=99s=E2=80=94could eventu=
ally be compromised
>>>> by quantum adversaries. If these coins were hacked and put back into
>>>> circulation, the resulting market shock would be catastrophic. The for=
ced
>>>> 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 concept=
ually
>>>>> 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 norm=
al.
>>>>>
>>>>> 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 pri=
vate
>>>>> key for a pq-safe scheme. It may also be possible that since we know =
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 dire=
ctly
>>>>> 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 p=
art of
>>>>> an audit of shielded funds.
>>>>>
>>>>> There are likely hidden complexities in this idea that may cause it t=
o
>>>>> 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 pre=
tenses.
>>>>>
>>>>> This only works for p2pkh, anything prior to this is immediately
>>>>> vulnerable to key inversion, but Satoshi owns most of those coins 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 idea is clear though.
>>>>>
>>>>> On Wed, Feb 19, 2025 at 10:47=E2=80=AFAM Agustin Cruz <agustin.cruz@g=
mail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Hunter,
>>>>>>
>>>>>> I appreciate the work you=E2=80=99re doing on BIP-360 for Anduro. Yo=
ur point
>>>>>> about not =E2=80=9Cconfiscating=E2=80=9D old coins and allowing thos=
e with quantum
>>>>>> capabilities to free them up is certainly a valid one, and I underst=
and the
>>>>>> argument that any inflationary impact could be transitory.
>>>>>>
>>>>>> From my viewpoint, allowing quantum-capable adversaries to
>>>>>> reintroduce 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 disr=
upt economic
>>>>>> assumptions built around the current distribution of coins. While so=
me
>>>>>> 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 i=
t
>>>>>> becomes imminent.
>>>>>>
>>>>>> I agree that Q-day won=E2=80=99t necessarily be a single, catastroph=
ic
>>>>>> moment. It will likely be gradual and subtle, giving the network som=
e time
>>>>>> to adapt. That said, one challenge is ensuring we don=E2=80=99t find=
 ourselves in
>>>>>> an emergency scramble the moment a capable quantum machine appears. =
A
>>>>>> forced or proactive migration is an admittedly strong measure, but i=
t
>>>>>> attempts to address the scenario where a slow, creeping capability b=
ecomes
>>>>>> a sudden attack vector once it matures. In that sense, =E2=80=9Crush=
ing=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
>>>>>> <hunter@surmount.systems> escribi=C3=B3:
>>>>>>
>>>>>>> I don't see why old coins should be confiscated. The better option
>>>>>>> is to let those with quantum computers free up old coins. While thi=
s might
>>>>>>> have an inflationary impact on bitcoin's price, to use a turn of ph=
rase,
>>>>>>> the inflation is transitory. Those with low time preference should =
support
>>>>>>> returning lost coins to circulation.
>>>>>>>
>>>>>>> Also, I don't see the urgency, considering the majority of coins ar=
e
>>>>>>> in either P2PKH, P2WPKH, P2SH, and P2WSH addresses. If PQC signatur=
es
>>>>>>> aren't added, such as with BIP-360, there will be some concern arou=
nd long
>>>>>>> exposure attacks on P2TR coins. For large amounts, it would be smar=
t to
>>>>>>> modify wallets to support broadcasting transactions to private memp=
ool
>>>>>>> services such as Slipstream, to mitigate short exposure attacks. Th=
ose will
>>>>>>> also be rarer early on since a CRQC capable of a long exposure atta=
ck is
>>>>>>> much simpler than one capable of pulling off a short exposure attac=
k
>>>>>>> against a transaction in the mempool.
>>>>>>>
>>>>>>> Bitcoin's Q-day likely won't be sudden and obvious. It will also
>>>>>>> take time to coordinate a soft fork activation. This shouldn't be r=
ushed.
>>>>>>>
>>>>>>> In the interest of transparency, it's worth mentioning that I'm
>>>>>>> working on a BIP-360 implementation for Anduro. Both Anduro and Sli=
pstream
>>>>>>> are MARA services.
>>>>>>>
>>>>>>> On Tuesday, February 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin C=
ruz 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 not =
migrate
>>>>>>>> in time, and under normal circumstances, many would argue that unu=
sed P2PKH
>>>>>>>> funds are safe from a quantum adversary. However, the intent here =
is to be
>>>>>>>> proactive rather than reactive.
>>>>>>>>
>>>>>>>> The concern isn=E2=80=99t solely about funds in active wallets. Co=
nsider
>>>>>>>> that if we don=E2=80=99t implement a proactive migration, any Bitc=
oin 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 co=
uld be
>>>>>>>> hacked and put back into circulation. Such an outcome would not on=
ly
>>>>>>>> disrupt the balance of supply but could also undermine the trust a=
nd
>>>>>>>> security that Bitcoin has built over decades. In short, the conseq=
uences of
>>>>>>>> a reactive measure in a quantum emergency could be far more catast=
rophic.
>>>>>>>>
>>>>>>>> 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 le=
aves us
>>>>>>>> with little margin for error. By enforcing a migration now, we cre=
ate a
>>>>>>>> window for the entire community to transition safely=E2=80=94assum=
ing we set the
>>>>>>>> deadline generously and provide ample notifications, auto-migratio=
n 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 thi=
s
>>>>>>>>> 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 a=
t
>>>>>>>>> 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 ke=
ys
>>>>>>>>> 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 emergen=
cy
>>>>>>>>> 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...@g=
mail.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 attac=
ks on
>>>>>>>>> ECDSA. The idea is to force a proactive migration of funds to
>>>>>>>>> quantum-resistant addresses before quantum computers become capab=
le of
>>>>>>>>> compromising the current cryptography.
>>>>>>>>> >
>>>>>>>>> > The migration window is intended to be sufficiently long
>>>>>>>>> (determined by both block height and community input) to provide =
ample 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 m=
anner
>>>>>>>>> would cause serious financial damage to anyone holding legacy fun=
ds, 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
>>>>>>>>> Improvement Proposal (BIP) titled Quantum-Resistant Address Migra=
tion
>>>>>>>>> Protocol (QRAMP). The goal of this proposal is to safeguard Bitco=
in against
>>>>>>>>> potential future quantum attacks by enforcing a mandatory migrati=
on period
>>>>>>>>> for funds held in legacy Bitcoin addresses (secured by ECDSA) to
>>>>>>>>> quantum-resistant addresses.
>>>>>>>>> >>>
>>>>>>>>> >>> The proposal outlines:
>>>>>>>>> >>>
>>>>>>>>> >>> Reducing Vulnerabilities: Transitioning funds to
>>>>>>>>> quantum-resistant schemes preemptively to eliminate the risk pose=
d by
>>>>>>>>> quantum attacks on exposed public keys.
>>>>>>>>> >>> Enforcing Timelines: A hard migration deadline that forces
>>>>>>>>> timely action, rather than relying on a gradual, voluntary migrat=
ion 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 a=
s
>>>>>>>>> the risk of permanent fund loss, uncertain quantum timelines, and=
 the
>>>>>>>>> potential for chain splits. It also details backwards compatibili=
ty
>>>>>>>>> measures, comprehensive security considerations, an extensive sui=
te of test
>>>>>>>>> cases, and a reference implementation plan that includes script i=
nterpreter
>>>>>>>>> changes, wallet software updates, and network monitoring tools.
>>>>>>>>> >>>
>>>>>>>>> >>> For your convenience, I have published the full proposal on m=
y
>>>>>>>>> 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 =
security
>>>>>>>>> and resilience of the Bitcoin network in the quantum computing er=
a.
>>>>>>>>> >>>
>>>>>>>>> >>> 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-8=
303-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-9a9=
f-3310ea242194n%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/f9e233e0-9d87-4e71-9a=
9f-3310ea242194n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>>> 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/CAJDmzYz%3D52MGGLE0ZWm5=
tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/bitcoindev/CAJDmzYz%3D52MGGLE0ZWm=
5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com?utm_medium=3Demail&utm_sou=
rce=3Dfooter>
>>>>>> .
>>>>>>
>>>>>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAJDmzYznDYi8GgmDof_6sJ%3DkJ1SZUMo-gAo9rgnrthi_p7ur_w%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">Hi everyone,</div><div dir=3D"auto">
<p dir=3D"ltr">I wanted to kick off a discussion on how the Quantum-Resista=
nt Address Migration Protocol (QRAMP), could integrate smoothly with the ex=
isting BIP-360 (Pay to Quantum Resistant Hash) proposal. Both of these prop=
osals aim to protect Bitcoin from potential quantum computing threats, but =
they approach the problem from slightly different angles. I believe they co=
uld complement each other nicely.</p>
<p dir=3D"ltr">The QRAMP proposal introduces a mandatory migration period a=
fter which spending from legacy ECDSA-based addresses becomes invalid. The =
goal is to push users proactively towards quantum-resistant addresses, ensu=
ring older, potentially vulnerable public keys are phased out before quantu=
m computing poses a real threat.</p>
<p dir=3D"ltr">Meanwhile, BIP-360 defines a new quantum-resistant address f=
ormat and associated transaction validation rules. It introduces hash-based=
 and hybrid post-quantum signatures, designed specifically to integrate smo=
othly with Bitcoin=E2=80=99s current infrastructure, avoiding sudden disrup=
tions or significantly increased block sizes.</p>
<p dir=3D"ltr">Together, I see QRAMP and BIP-360 forming a robust approach.=
 QRAMP provides a clear timeline and incentive for users to migrate their f=
unds, while BIP-360 provides the technical standard and address types to wh=
ich users can securely transition. Wallets and infrastructure could offer c=
lear user guidance throughout the transition period, supporting both legacy=
 and quantum-resistant addresses simultaneously. Once QRAMP&#39;s deadline =
passes, the network smoothly moves forward with only quantum-resistant addr=
esses being valid.</p>
<p dir=3D"ltr">I think this combined approach could provide a secure, user-=
friendly transition path, reducing the potential disruption to the network =
while effectively mitigating quantum risks. I&#39;d really appreciate your =
thoughts, concerns, or ideas on how we could refine this integration.</p><p=
 dir=3D"ltr">Regards,</p><p dir=3D"ltr">Agust=C3=ADn Cruz=C2=A0</p></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">El mi=C3=
=A9, 19 de feb de 2025, 7:05=E2=80=AFp.=C2=A0m., Dustin Ray &lt;<a href=3D"=
mailto:dustinvonsandwich@gmail.com" target=3D"_blank">dustinvonsandwich@gma=
il.com</a>&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"auto">I don&#39;t disagree personally with most of what you&#39;re s=
aying except where the real catastrophe lies. Id argue it&#39;s catastrophi=
c for the value proposition of a blockchain to effectively seize funds, whi=
ch is what your proposal does in case anyone fails to migrate before the de=
adline.</div><div dir=3D"auto"><br></div><div dir=3D"auto">On the other han=
d, it&#39;s equally catastrophic for digital signatures to be broken and fu=
nds lost in any scenario. So it seems we are staring down two extremely unt=
enable outcomes, both of which see the fundamental properties of a blockcha=
in shattered in one way or another.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">I hope it doesn&#39;t come down to having to choose one or the =
other. There is very serious financial harm that will occur in either scena=
rio. I dearly hope there is a practical technological solution that allows =
for safe and fair migration, and in my mind and experience, I don&#39;t thi=
nk we have to resign ourselves to a zero sum game just yet. But I appreciat=
e your proposal and the proactive nature of this discussion, it&#39;s impor=
tant to have these conversations now rather than later.</div><div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19,=
 2025 at 1:50=E2=80=AFPM Agustin Cruz &lt;<a href=3D"mailto:agustin.cruz@gm=
ail.com" rel=3D"noreferrer" target=3D"_blank">agustin.cruz@gmail.com</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;b=
order-left-color:rgb(204,204,204)"><div dir=3D"ltr"><div>Hi Dustin,</div><b=
r>My proposal is not about locking down or confiscating funds. It is about =
ensuring that vulnerable pre-P2PKH funds are migrated to quantum-safe addre=
sses before any quantum adversary can exploit them. Even though P2PKH addre=
sses are secured by hashes that are currently considered safe, relying sole=
ly on that safety may leave us exposed in the future, especially as quantum=
 capabilities continue to evolve. Without a forced migration, we risk leavi=
ng a significant portion of the coin supply vulnerable. Consider the possib=
ility that if we don=E2=80=99t act, any Bitcoin in lost wallets could event=
ually be hacked and put back into circulation. Such a scenario would be cat=
astrophic for the network.<br><br>I believe that by enforcing a deadline fo=
r migration, we provide rightful owners with a clear, non-negotiable opport=
unity to secure their funds. This approach is not merely hypothetical. It i=
s a proactive measure that addresses the imminent risk of quantum attacks. =
While turnstile mechanisms 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 necess=
ary to protect the long-term security of Bitcoin.<br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025=
 at 6:35=E2=80=AFPM Dustin Ray &lt;<a href=3D"mailto:dustinvonsandwich@gmai=
l.com" rel=3D"noreferrer" target=3D"_blank">dustinvonsandwich@gmail.com</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1e=
x;border-left-color:rgb(204,204,204)"><div></div><div><div dir=3D"auto" sty=
le=3D"font-family:-apple-system,&quot;helvetica neue&quot;;font-size:1rem;f=
ont-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:1px;text-decoration:none;ba=
ckground-color:rgba(0,0,0,0);border-color:rgb(49,49,49);color:rgb(49,49,49)=
">To be clear, the turnstile approach is definitely a forced migration. It =
just means that instead of permanently confiscating funds and removing them=
 from circulation, you force the rightful owners of those funds to move the=
m into quantum safe addresses, assuming the existence of a hypothetical tur=
nstile mechanism. There&#39;s too many hypotheticals with this idea right n=
ow to give it any more than a cursory glance, but turnstiles have been buil=
t before and could potentially be built again in this scenario.</div><div d=
ir=3D"auto" style=3D"font-family:-apple-system,&quot;helvetica neue&quot;;f=
ont-size:16px;font-style:normal;font-weight:400;letter-spacing:normal;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:1px;text-dec=
oration:none;background-color:rgba(0,0,0,0);border-color:rgb(49,49,49);colo=
r:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-family:-apple-sy=
stem,&quot;helvetica neue&quot;;font-size:1rem;font-style:normal;font-weigh=
t:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space=
:normal;word-spacing:1px;text-decoration:none;background-color:rgba(0,0,0,0=
);border-color:rgb(49,49,49);color:rgb(49,49,49)">For further clarification=
, I&#39;m suggesting that we enforce migration of unspent funds in p2pkh ad=
dresses because they are already secured by hashes which are currently conj=
ectured to remain safe against a quantum adversary. Pre-p2pkh addresses are=
 probably the most vulnerable but few of these had seen use comparatively a=
nd may require confiscation.</div><div dir=3D"auto" style=3D"font-family:-a=
pple-system,&quot;helvetica neue&quot;;font-size:16px;font-style:normal;fon=
t-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:1px;text-decoration:none;background-color:rgba(=
0,0,0,0);border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div><div dir=
=3D"auto" style=3D"font-family:-apple-system,&quot;helvetica neue&quot;;fon=
t-size:1rem;font-style:normal;font-weight:400;letter-spacing:normal;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:1px;text-decor=
ation:none;background-color:rgba(0,0,0,0);border-color:rgb(49,49,49);color:=
rgb(49,49,49)">If your idea is to simply lock down and confiscate any pre-p=
q safe funds, I resolutely disagree with that decision and I am fairly conf=
ident that consensus will fail to materialize around that. What I&#39;m sug=
gesting however is that your idea is realistic and sound if we assume the e=
xistence of some mechanism that allows rightful owners of pre-pq funds the =
opportunity to do nothing except migrate to safe addresses which then resol=
ves the issue.</div><div dir=3D"auto" style=3D"font-family:-apple-system,&q=
uot;helvetica neue&quot;;font-size:1rem;font-style:normal;font-weight:400;l=
etter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:1px;text-decoration:none;background-color:rgba(0,0,0,0);borde=
r-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div></div><div><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025=
 at 1:07=E2=80=AFPM Agustin Cruz &lt;<a href=3D"mailto:agustin.cruz@gmail.c=
om" rel=3D"noreferrer" target=3D"_blank">agustin.cruz@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border=
-left-color:rgb(204,204,204)"><div dir=3D"auto"><p dir=3D"ltr">Hi Dustin,</=
p><p dir=3D"ltr">I remain convinced that a forced migration mechanism=E2=80=
=94with a clear block height deadline after which quantum-unsafe funds beco=
me unspendable=E2=80=94is the more robust and secure approach. Here=E2=80=
=99s why:</p><p dir=3D"ltr">
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.</p><p dir=3D"ltr">
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.</p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">El mi=C3=A9, 19 de feb de 2025, 5:10=E2=80=AFp.=C2=A0m., Dustin Ray &=
lt;<a href=3D"mailto:dustinvonsandwich@gmail.com" rel=3D"noreferrer" target=
=3D"_blank">dustinvonsandwich@gmail.com</a>&gt; escribi=C3=B3:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(=
204,204,204)"><div dir=3D"auto">It&#39;s worth considering a hypothetical b=
ut as of yet unknown middle ground solution, again nothing like this exists=
 currently but conceptually it would be interesting to explore:</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">1. At some block height deemed appr=
opriate, modify consensus so that any pre-quantum unspent funds are restric=
ted from being spent as normal.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">2. Develop a new transaction type whose sole purpose is to migrat=
e funds from a quantum unsafe address to a safe one.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">3. This new transaction type is a quantum safe=
 digital signature, but here&#39;s the hypothetical: It is satisfied by dev=
eloping 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 possib=
le that since we know the hash of the public key, perhaps we can invent som=
e mechanism whereby a quantum safe signature is created from an ecdsa priva=
te key that directly implies knowledge of a secret key that derived the kno=
wn public key.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In this w=
ay, we create a kind of turnstile that can safely transition funds from uns=
afe 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 s=
hielded funds.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">The=
re are likely hidden complexities in this idea that may cause it to be comp=
letely unworkable, but a theoretical transition mechanism both prevents a h=
eavy handed confiscation of funds and also prevents funds from being stolen=
 and injected back into the supply under illegitimate pretenses.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">This only works for p2pkh, anythin=
g prior to this is immediately vulnerable to key inversion, but Satoshi own=
s most of those coins as far as we know, so confiscating them might not be =
as controversial.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;=
m typing this on my phone so sorry for the lack of detailed references. I t=
hink the core idea is clear though.</div><div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 19, 2025 at 10:47=E2=80=
=AFAM Agustin Cruz &lt;<a href=3D"mailto:agustin.cruz@gmail.com" rel=3D"nor=
eferrer noreferrer" target=3D"_blank">agustin.cruz@gmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-le=
ft-color:rgb(204,204,204)"><div dir=3D"auto"><p dir=3D"ltr">Hi Hunter,</p><=
p dir=3D"ltr">I appreciate the work you=E2=80=99re doing on BIP-360 for And=
uro. Your point about not =E2=80=9Cconfiscating=E2=80=9D old coins and allo=
wing those with quantum capabilities to free them up is certainly a valid o=
ne, and I understand the argument that any inflationary impact could be tra=
nsitory.</p>
<p dir=3D"ltr">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.</p><p dir=3D"ltr">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.</p></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">El mi=C3=A9, 1=
9 de feb de 2025, 1:31=E2=80=AFp.=C2=A0m., Hunter Beast &lt;hunter@surmount=
.systems&gt; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;padding-left:1ex;border-left-color:rgb(204,204,204)">I don&#39;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&#39;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.<div><br></div><div>Also, I don&#39;t see the urgency, conside=
ring the majority of coins are in either P2PKH, P2WPKH, P2SH, and P2WSH add=
resses. If PQC signatures aren&#39;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><div><br></div><=
div>Bitcoin&#39;s Q-day likely won&#39;t be sudden and obvious. It will als=
o take time to coordinate a soft fork activation. This shouldn&#39;t be rus=
hed.</div><div><br></div><div>In the interest of transparency, it&#39;s wor=
th mentioning that I&#39;m working on a BIP-360 implementation for Anduro. =
Both Anduro and Slipstream are MARA services.</div><div><br></div><div clas=
s=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, Februa=
ry 11, 2025 at 9:01:51=E2=80=AFPM UTC-7 Agustin Cruz wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204=
,204,204)"><div dir=3D"auto"><p dir=3D"ltr">Hi Dustin:</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">El mar, 11 de feb de 2025, 9:48=
=E2=80=AFp.=C2=A0m., Dustin Ray &lt;<a rel=3D"nofollow noreferrer noreferre=
r noreferrer">dustinvo...@gmail.com</a>&gt; escribi=C3=B3:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,=
204,204)">I think youre going to have a tough time getting consensus on thi=
s<br>
proposal. It is an extraordinary ask of the community to instill a<br>
change that will essentially void out a non-trivial part of the coin<br>
supply, especially when funds behind unused P2PKH addresses are at<br>
this point considered safe from a quantum adversary.<br>
<br>
In my opinion, where parts of this proposal make sense is in a quantum<br>
emergency in which an adversary is actively extracting private keys<br>
from known public keys and a transition must be made quickly and<br>
decisively. In that case, we might as well consider funds to be lost<br>
anyways. In any other scenario prior to this hypothetical emergency<br>
however, I have serious doubts that the community is going to consent<br>
to this proposal as it stands.<br>
<br>
On Tue, Feb 11, 2025 at 4:37=E2=80=AFPM Agustin Cruz &lt;<a rel=3D"noreferr=
er nofollow noreferrer noreferrer noreferrer">agusti...@gmail.com</a>&gt; w=
rote:<br>
&gt;<br>
&gt; Hi Dustin<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt;<br>
&gt; El mar, 11 de feb de 2025, 9:15=E2=80=AFp. m., Dustin Ray &lt;<a rel=
=3D"noreferrer nofollow noreferrer noreferrer noreferrer">dustinvo...@gmail=
.com</a>&gt; escribi=C3=B3:<br>
&gt;&gt;<br>
&gt;&gt; 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.<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Feb 11, 2025 at 4:10=E2=80=AFPM Agustin Cruz &lt;<a rel=3D=
"noreferrer nofollow noreferrer noreferrer noreferrer">agusti...@gmail.com<=
/a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Dear Bitcoin Developers,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The proposal outlines:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Reducing Vulnerabilities: Transitioning funds to quantum-resis=
tant schemes preemptively to eliminate the risk posed by quantum attacks on=
 exposed public keys.<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For your convenience, I have published the full proposal on my=
 GitHub repository. You can review it at the following link:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Quantum-Resistant Address Migration Protocol (QRAMP) Proposal =
on GitHub<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thank you for your time and consideration.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Best regards,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Agustin Cruz<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt;&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an email to <a rel=3D"noreferrer nofollow noreferrer noreferrer no=
referrer">bitcoindev+...@googlegroups.com</a>.<br>
&gt;&gt;&gt; To view this discussion visit <a href=3D"https://groups.google=
.com/d/msgid/bitcoindev/08a544fa-a29b-45c2-8303-8c5bde8598e7n%40googlegroup=
s.com" rel=3D"noreferrer noreferrer nofollow noreferrer noreferrer noreferr=
er" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/08a544fa=
-a29b-45c2-8303-8c5bde8598e7n%40googlegroups.com</a>.</blockquote></div></b=
lockquote></div></blockquote></div><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,20=
4)"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204)"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:r=
gb(204,204,204)"><br></blockquote></div></blockquote></div></blockquote></d=
iv></blockquote></div></div></blockquote></div></blockquote></div></div></b=
lockquote></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style=
:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;bo=
rder-left-color:rgb(204,204,204)"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204=
)"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
padding-left:1ex;border-left-color:rgb(204,204,204)"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-co=
lor:rgb(204,204,204)"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;b=
order-left-color:rgb(204,204,204)">
</blockquote></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer noreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@g=
ooglegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f9e233e0-9d87-4e71-9a9f-3310ea242194n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer noreferre=
r" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/f9e233e0-=
9d87-4e71-9a9f-3310ea242194n%40googlegroups.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups=
.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAJDmzYz%3D52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gma=
il.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer norefe=
rrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/CAJDmz=
Yz%3D52MGGLE0ZWm5tmfLUAZEo2tYQutHb4sMvjKbayOAHg%40mail.gmail.com</a>.<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</div></div>

<p></p>

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

--0000000000000ce57b062fc4ff47--