Delivery-date: Mon, 15 Sep 2025 12:20:33 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uyEkY-0007rG-I1 for bitcoindev@gnusha.org; Mon, 15 Sep 2025 12:20:33 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-319c4251787sf6488696fac.2 for ; Mon, 15 Sep 2025 12:20:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1757964024; cv=pass; d=google.com; s=arc-20240605; b=dut2EewSsy4x1bZ1npzy8rh/hqE7cGNvF93qMPJ0awr4IH0TP37lJLOpyW5QlQXOYD NwnbyUDFy7/a4gldI4lkkm//BZ1XkrKayRWh6qO7BwWX1tQ4LqefgfaPPlFxf5RslYmp WlOtZckl6z2kVFibdpq5T9kF7ieJbcFJI804u8oh2+SY8ZQicS0lOVSGsxmamXJbxq6R Webe7Iub4YoLRa3q2QS1pKbNVFGldC+9sbtlAMn/X6VDbyosZBkgz2VBujp8TaiKGS3K L+qN8g+6aMU8nQWZg7FZReGl/Swk/O+zgG9l+ZTZNw229hbXjKu47+R7aHr9kOMMvHKY 6+Pw== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=TOY++4Kmx7AKgLsAaLTgP/RIL3p8RtTXOBKw06rw2Ik=; fh=YMBgo1E/TL9fXq/Gt7J+Ipoa4JIufVOa39viDuHXWkg=; b=DY8RpXKiL9+TUbAg9qpDkd28r8VrwAo41Pn2d3Ee+RBxCBKKO4rip3PfyN1cBZknMh ZclZMOvvtNnAlwA8xLrMCnOlzeJ9s66PJJDXMQF4yaC3cH62dThd5vn6VdlrwceiiDoF Hl/1OOUVg3RBfyM02SjjSjTxRsJFyJ+BX9fo0q/gQ4zRa8SL9yudLNc8pgWZndzAqEVU j9UeLdmaNxCxXVxKrCrTI7cXclOTGqjwVIjFAaYTS/NJwdM+oygoEM9q6wkOGbfQ6h2J vBYe43z4bTEk2K2tIgFXva620GMA5xQpiyXp5LSNLaO4/DtNlkNnFKWPFgEiYrlFEmuV UPGA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=gAvx3C8T; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1757964024; x=1758568824; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=TOY++4Kmx7AKgLsAaLTgP/RIL3p8RtTXOBKw06rw2Ik=; b=xXEUPREI1P/d2XMhNJ36n9b6ASIwbssiB32Nci/M0xEtZvaRv+PaE73zMnjxPdCrQN ltUy2nqS7xzWt3MejTyh6yoyoehZ+5y9ZQ0kkGUi9f2sw2T7HA4WV6eeeVrVOoKKtm5b FAXZ75tqnaJGIC4Ku7kqTC5h74XwEofeFdBLHXK9+bx9sgZvatjz+YKx13GdXm09f/E1 FmduqFKdRLxlaAc019/lTzrDQGK2QPCh+vcETvsp9B/WXnjVREHnC9/0hmMAY/8rG0/Z 6ZfwrirvrKrf6n+mPsDP9Y1jtOVGsm9W9/0ZFNmjc6k46G8TaZwTe0uo+mvRstiPhuYb owbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757964024; x=1758568824; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TOY++4Kmx7AKgLsAaLTgP/RIL3p8RtTXOBKw06rw2Ik=; b=rudcuBBW7fWHTIpt9vYc9IUQXk5ZqExS5W8waPbWGXn9vkenHoJ/G8ENCdLF08i4Uw nZ6FxXT45XtT2FIw34fIWfUWQS9+Xaj/uJJ8F/zMSlq1BZ6NUMe9PeHKFEB+VZS4X7tO p0Kge1JjC+uQ9YA9Mu0bbz8Xb1xLZn7kutmnp7RjsA7RL/Ewe0At2Y2ZGZ+2EpDwbVcL YYxUW3cYCfp/iHvdpallJ4rHOqMZ2KQLtvXgWwKRv66JzakKFP4F1xbUaP5Yzfl1xXJa UbovCHPDeeOTPuciOvyzTtvn7wRhaw6dRUGrgQv3RyoZRoi2+oRNfObMVyICGOopKhUW xxLg== X-Forwarded-Encrypted: i=2; AJvYcCVVLt6ZB4U4qmEQojnfS/nZbAbJciPZbjbP4NMmoaJQcI84clXvDYeR6+qJuuzknMPdvNj83H+Wqi5y@gnusha.org X-Gm-Message-State: AOJu0YyznBbzZzmnx3/8cWasXmm0XJNFCaVk7GwZc78T/Mp1ja/IUekb dO/jtIqww5c+AZyb+Eo+UkUdGBLHZXCb86Y0FaTgsgU23zbF/lBqS5E2 X-Google-Smtp-Source: AGHT+IGkLEUej5nKQz+xK3fjIS4SH1f/keePln4myjHmdrbn8x7ozWEoqwFrb01FHXtFufu1oAdB4Q== X-Received: by 2002:a05:6871:5229:b0:315:6c51:f544 with SMTP id 586e51a60fabf-32e58e71163mr7535172fac.44.1757964023610; Mon, 15 Sep 2025 12:20:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcZv2lIHVNkSLTb8iPPsoH5rKzdXODBHP6OVT0zelegdQ== Received: by 2002:a05:687c:2ba1:b0:330:f9af:ee37 with SMTP id 586e51a60fabf-330f9b02ce0ls1522755fac.1.-pod-prod-01-us; Mon, 15 Sep 2025 12:20:20 -0700 (PDT) X-Received: by 2002:a05:6808:1b06:b0:434:10d3:703f with SMTP id 5614622812f47-43b8d8de41fmr7270804b6e.13.1757964020175; Mon, 15 Sep 2025 12:20:20 -0700 (PDT) Received: by 2002:a05:6504:4091:b0:2c0:aeab:e1f7 with SMTP id a1c4a302cd1d6-2c5746e7e9emsc7a; Mon, 15 Sep 2025 09:52:59 -0700 (PDT) X-Received: by 2002:a05:651c:20cc:20b0:337:ed76:7212 with SMTP id 38308e7fff4ca-3513f85dd99mr33418851fa.40.1757955177369; Mon, 15 Sep 2025 09:52:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1757955177; cv=none; d=google.com; s=arc-20240605; b=cQGG2P4LeOktS4Qmlh9BSBh17nWaYbf38kl9vlACP818uhp9N8MoTbfl8LQhM3d5yR DvpOLW2zoWc4FZk1OUuc4J/Nq6lnI4ilbcrqWsH6blBNMiKSp0rwZ4xFmIGkWA1nnkbq v1XFpxhDuIMZtOtnbncK1Y1fYX1j2vQGZL7R6U0XTeeDeNayZPxxYpV+fqFYB8WJXUqK Kp60VjK7Ej1PdFt0XXZuFYf7ZXhhQBLGwv21JaQR3dEyQuPn1yhmD5bIfj3e15Ns9fVi lJX5fXQ+vw+3CFN+YQTVVAfHZb+kbN09+ITI3g1Qip78J/fb47FlFWntPHrya/Yo1tz7 4f8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=6fWt4InSmiL2AeM3SlJprBMdFmzuPOdKUzfd0l41vXg=; fh=yX/ghkT6dP+ZKvK7/b8r8aOQXrA/vrdjWu8n4+C271k=; b=Vg26igi7YOwogIXakQ34Koj+MB2an5R8ECaT9+IZwrgn3AmVM1BDkfFFMU272I1/f0 oQh6DC2yX4FI6VxH5jEwL0va6OT1kB9SWbynnveP3ec9zzKqRfh/PTWoa3GOFEl6XLS5 rsVHZsJ4ZnXr3bsR/QGvkpIuUX1TI5qKQfBCjF0b4hRUNu3iPWHijvFRhIR4dKpGO3HS y6cpC1nVrNcVl47chmUihHG8e2xypo8pbSk4Ii2adufF2jFOANQVVc0gA/mw0uXUpk9Y PsDj0F9gvG0OpAmnZOzFg4QYMs7pJvOCEF0q4PIv6/hdLwLoP/amQkp3kvKj7CbrW8UU iHIQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=gAvx3C8T; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-35129ddee24si2068831fa.4.2025.09.15.09.52.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Sep 2025 09:52:57 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16; Date: Mon, 15 Sep 2025 16:52:48 +0000 To: James T From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: [BIP Proposal] No burn, Quantum Migration Proposal, Quantum Secure Asset Verification & Escrow (QSAVE) Message-ID: In-Reply-To: References: <2e635098-a8f5-43d6-b8e9-5971ba8ba218n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 22fb62464d506ad738dde10ca0a38d5a5ee91c86 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------e5b0b37346044e40971b2484407204c706d57ee6dc0fb9c829cc85966aed03a1"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=gAvx3C8T; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: 1.2 (+) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------e5b0b37346044e40971b2484407204c706d57ee6dc0fb9c829cc85966aed03a1 Content-Type: multipart/mixed;boundary=---------------------0af7bc860dc3678ef701839f22a7fe4d -----------------------0af7bc860dc3678ef701839f22a7fe4d Content-Type: multipart/alternative;boundary=---------------------92c15b7d3d80cb94fc64e34e98353c5f -----------------------92c15b7d3d80cb94fc64e34e98353c5f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi James, Notice how satoshi is talking about replacing the hash function SHA256 in t= he context of blocks and proof-of-work, and that if SHA256 is broken we cou= ld walk the chain back a bit and then "continue from there with a new hash = function". He's saying the community can come to consensus on a new hash al= go=C2=A0and then nodes continue operating under the same decentralized PoW = protocol from then onwards, just with a slightly cryptographic primitive un= derlying it. He is most definitely not=C2=A0saying the community should vest the power t= o mint new blocks in some trusted block-producing organization. That would = be more closely analogous to what QSAVE is proposing, and would likewise be= a total reversal of the principles that Bitcoin was founded on. Unfortunately, a consensus hash algorithm switcheroo is much easier to engi= neer than migrating the UTXO set to a new PQ secure signing primitive, beca= use with UTXOs we're talking about an authentication (ownership) problem, r= ather than a coordination (consensus) problem. As you know, the network can= 't just hot-swap=C2=A0signing algorithms for old UTXOs the same way we can = hot-swap hash algorithms for new blocks. For the curious, here is the original thread where Satoshi said these thing= s.=C2=A0https://bitcointalk.org/index.php?topic=3D191.0 regards, conduition On Friday, September 5th, 2025 at 9:45 AM, 'James T' via Bitcoin Developmen= t Mailing List wrote: > If we are going to quote Satoshi, he imagined that some group of people= =E2=80=94the consensus=E2=80=94could come together and agree on what the ch= ain should say if the underlying maths failed. =E2=80=9CIf SHA-256 became c= ompletely broken, I think we could come to some agreement about what the ho= nest blockchain was before the trouble started, lock that in, and continue = from there with a new hash function.=E2=80=9D >=20 > This is exactly what I am proposing; that we come to some agreement about= what the honest blockchain. If ECSDA is compromised, the only way to fix i= t will be to reach a consensus, and that will require the labor of people. >=20 > So far from being a non-negotiable point, this was anticipated from the b= eginning. I do agree with the sentiment. It would be great to have a protoc= ol that operated independently of any human involvement but, the very fact = that we are having this debate means we are past that point. We will have t= o decide which path to take and I think the QSAVE proposal does the least h= arm and the most good. >=20 > Best, >=20 > James >=20 >=20 > On Tuesday, August 19, 2025 at 3:54:01=E2=80=AFAM UTC-7 Javier Mateos wro= te: >=20 > > Hi James, thanks for opening this discussion. > > One point that is non-negotiable in Bitcoin is "embedding" in the code = a group of people to arbitrate claims. That goes against de very essence of= the network ("trustless") and was part of the reason Bitcoin was created. > >=20 > > While not strictly canonical from Satoshi, his messages are clear: "wha= t is needed is an electronic payment system based on cryptographic proof in= stead of trust..." and "lost coins only make everyone else's coins worth sl= ightly more..." Coin loss is an inherent risk of the system, but that shoul= dn=C2=B4t be confused with designing a protocol that automatically protects= funds and transactions via human arbiters. > >=20 > > That's why I consider this (and other) debates about preparing Bitcoin = to survive in a potentially dangerous quantum enviroment valid, whether tha= t happens in 5 years or 100. Sooner or later, upgrades will be needeed, but= the response must be technical and opt-in (migration to post-quantum signa= tures, inheritable vaults, voluntary mechanisms), not a return to introduci= ng judges into consensus. > >=20 > > Best regards, > > Javier Mateos > >=20 > > El lunes, 18 de agosto de 2025 a las 14:12:36 UTC-3, James T escribi=C3= =B3: > >=20 > > > I am suggesting that Bitcoin elects people who can arbitrate reasonab= le claims. The Bitcoin dev team proposing a burn solution is the same probl= em you articulate: a small group of people (80% of miners) voting to burn c= oins. I don't see a way around this fundamental problem. The keys will fail= in the future; some human intervention is going to happen. Remember, if th= e burn happens, tens of thousands of people will open safety deposit boxes = full of Bitcoin addresses and find them zeroed out. Only our solution provi= des a solution to this and preserves the Digital Gold promise. > > >=20 > > > We like to assume there is no human intervention in Bitcoin and it's = all algorithmic, but that's not true. There is an army of people working to= secure Bitcoin behind the scenes, including upfront KYC/AML and after-the-= fact recovery by private companies and law enforcement when there is a hack= . This all works on a worldwide basis today. > > >=20 > > > No lawyers have been involved in the drafting of our proposal. I woul= d welcome input, but it's really an engineering problem. Once Bitcoin keys = can no longer be relied on, what do we do to establish ownership? Deleting = ownership is certainly one solution, but I just don't think it is a fair on= e. > > >=20 > > > We are proposing our solution as either a hard fork or a no-fork. Eit= her way, we still have to solve the problem of a room full of elected exper= ts to adjudicate claims (obviously, they would be distributed worldwide, an= d often it could be achieved algorithmically). > > >=20 > > > In the no-fork solution, we encourage - maybe reward - white hat quan= tum actors to recover vulnerable Bitcoin under lost property law. If it's c= laimed, then it's returned; if not claimed, it's invested for the public go= od. This is then a race between white hat and black hat actors. BUT most la= ws will deter white hat actors because it might be considered computer misu= se. It would be really helpful if the Bitcoin consensus said, "We favor whi= te hat actors protecting Bitcoin". Although there are no Bitcoin terms and = conditions or EULA, this would massively protect white hats. > > >=20 > > > In the hard fork solution, instead of burning the coins, they go into= the recovery process, and here the Bitcoin consensus has made a clear prot= ocol decision, and there is no white hat actor risk. > > >=20 > > > I apologize for the lack of technical details at this point. We have = a lot of code written, and I did make a note to that effect in my submissio= n, but that bit seems to have been cut off. The recovery process has to obe= y the law and be distributable worldwide, and be fair, and I think it is po= ssible to do all that. Not simple, of course. In the meantime, there are pl= enty of best practices that can be implemented to better protect and prepar= e the network, which I know are in process. > > >=20 > > > Best, > > >=20 > > >=20 > > > James T > > >=20 > > >=20 > > > On Friday, August 8, 2025 at 7:07:25=E2=80=AFPM UTC-7 conduition wrot= e: > > >=20 > > > > Hi James, > > > > This is a curious idea, though I'm not seeing any technical details= of how this "BIP" would maintain Bitcoin's value as a distributed system. = It more-or-less sounds like you're suggesting to vest the power of quantum-= recovery using legal mechanisms (e.g. KYC, real-world evidence, etc)... in = a group of people working in an office somewhere? Surely you realize that's= impractical and un-scaleable. Besides, even if you had all the manpower ne= eded to do it, no one who owns Bitcoin would run a node which subscribes to= such consensus rules. A huge portion of the supply on that (hardforked) ch= ain would be effectively under the total control of a select few. Who elect= s these people? > > > >=20 > > > > It sounds like something a corporate lawyer would cook up if asked = how to solve the post-quantum-rescue problem. Not to say that legal opinion= s on quantum migration are unwanted. I'm sure there are interesting legal q= uestions to be debated around the rights of property holders in case of a p= ossible quantum-freeze. But this proposal at least is DOA because KYC canno= t be the answer, for practical and ethical reasons. > > > >=20 > > > > Perhaps, independent of any technical consensus upgrades, it would = be wise to encourage quantum adversaries to become benevolent, somehow. I'm= not sure what that looks like. If a quantum freeze doesn't happen, there o= ught to be legal guidelines for how quantum giants like Google or IBM shoul= d behave given their newfound quantum weaponry. It'll be impossible to full= y enforce any such rules, but if they want to play nice, someone should tel= l them what "playing nice" actually looks like. > > > >=20 > > > > regards, > > > > conduition > > > > On Thursday, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 James T wro= te: > > > >=20 > > > > > This BIP Proposal is an alternative to QRAMP or a quantum winner-= takes-all approach to the migration from a pre- to post quantum blockchain.= It could be implemented as a hard fork OR as a consensus that quantum acto= rs can legitimately move funds to safe addresses for protective custody and= public good. It could even go forward with no consensuses at all since it = is functionally equivalent to a quantum winner-takes-all at the protocol le= vel. > > > > >=20 > > > > > BIP: TBD > > > > >=20 > > > > > Title: Quantum Secure Asset Verification & Escrow (QSAVE) > > > > >=20 > > > > > Author: James Tagg > > > > >=20 > > > > > Status: Draft > > > > >=20 > > > > > Type: Standards Track > > > > >=20 > > > > > Layer: Consensus (Consensus / Soft Fork / Hard Fork) > > > > >=20 > > > > > Created: > > > > >=20 > > > > > License: > > > > >=20 > > > > > Abstract > > > > >=20 > > > > > This BIP proposes QSAVE (Quantum Secure Asset Verification & Escr= ow) - a non-sovereign wealth fund providing protective custody for Bitcoin = vulnerable to quantum attack (see Appendix for detailed vulnerability asses= sment). QSAVE preserves 100% of the principal for rightful owners while usi= ng generated returns to fund the protocol and global public good. It provid= es an alternative to the QRAMP (Quantum Resistant Asset Migration Protocol)= proposal (which makes coins unspendable) or taking no action (which allows= quantum appropriation, which many view as theft). This proposal addresses = coins that are dormant but acknowledges there may be coins that have quantu= m watermarks but have not migrated to quantum addresses. A separate BIP pro= posal will address this case. > > > > >=20 > > > > > Motivation > > > > >=20 > > > > > Chain analysis reveals 3.5-5.5 million Bitcoin (~17-28% of circul= ating supply) have exposed public keys vulnerable to quantum attack (see Ap= pendix: Quantum Vulnerability Assessment for detailed breakdown). > > > > >=20 > > > > > With sufficient education and proactive migration, a significant = portion of the 2-4M BTC in reused addresses could be moved to quantum-safe = addresses before the threat materializes. Modern wallets are increasingly i= mplementing best practices such as always sending change to fresh addresses= . However, some portion will inevitably remain unprotected when quantum com= puters arrive due to: > > > > >=20 > > > > > - Owners who don't follow Bitcoin news > > > > >=20 > > > > > - Forgotten wallets discovered years later > > > > >=20 > > > > > - Cold storage assumed long term safe > > > > >=20 > > > > > - Users who die and whose heirs have yet to uncover the keys > > > > >=20 > > > > > - Users who procrastinate or underestimate the threat > > > > >=20 > > > > > When quantum computers capable of running Shor's algorithm arrive= , the remaining vulnerable coins face two equally problematic outcomes: > > > > >=20 > > > > > 1. Quantum appropriation: First actors with quantum computers tak= e the coins > > > > >=20 > > > > > 2. Forced burning: The community burns coins preventatively (by m= aking them unspendable), breaking Bitcoin's promise as a store of value > > > > >=20 > > > > > This BIP proposes a third way: QSAVE - protective custody that pr= eserves ownership rights and puts dormant capital to work for humanity. > > > > >=20 > > > > > Note on "Theft": Bitcoin's protocol operates purely through crypt= ographic proofs, without built-in concepts of ownership or theft=E2=80=94th= ese are legal constructs that vary by jurisdiction. The community holds div= ergent views: some consider using advanced technology to derive private key= s as legitimate within Bitcoin's rules, while others view it as unethical a= ppropriation of others' funds. > > > > >=20 > > > > > QSAVE addresses both perspectives: If quantum key derivation is c= onsidered fair game, then racing to secure vulnerable coins before maliciou= s actors is simply good-faith participation in the system. If it's deemed u= nethical, then the community needs a consensus solution that balances prope= rty rights with Bitcoin's algorithmic nature. Either way, protective custod= y preserves coins for their rightful owners rather than allowing them to be= stolen or destroyed. > > > > >=20 > > > > > The Inheritance Vulnerability Window > > > > >=20 > > > > > Consider the "Auntie Alice's Bitcoin" scenario: Alice stores Bitc= oin in cold storage as inheritance for her grandchildren, with keys secured= in a safe deposit box. She doesn't follow Bitcoin news and remains unaware= of quantum threats. She passes away and by the time her heirs discover the= wallet, quantum computers capable of deriving private keys have emerged. > > > > >=20 > > > > > Three outcomes are possible: > > > > >=20 > > > > > 1. Without protection: Quantum actors take the grandchildren's in= heritance > > > > >=20 > > > > > 2. With burning: The network destroys legitimate inheritance fund= s > > > > >=20 > > > > > 3. With protective custody: Heirs can claim their inheritance wit= h proper evidence (will, keys, proof of box opening) > > > > >=20 > > > > > This illustrates why we cannot assume dormant equals lost and why= protective custody is the only approach that preserves legitimate ownershi= p rights. The inability to distinguish between lost coins and stored coins = is the fundamental reason protective custody is essential. > > > > >=20 > > > > > Principles > > > > >=20 > > > > > 1. Preserve the principal - 100% of recovered Bitcoin remains ava= ilable for rightful owners to reclaim at any time > > > > >=20 > > > > > 2. Ensure long-term store of value by avoiding any pre-emptive bu= rn (making coins unspendable) > > > > >=20 > > > > > 3. Avoid market shocks by keeping principal locked while only usi= ng generated returns > > > > >=20 > > > > > 4. Generate returns for the benefit of humanity through conservat= ive yield strategies > > > > >=20 > > > > > 5. Protect the Chain, ensuring smooth transition to post-quantum = era > > > > >=20 > > > > > 6. Enable priority recovery through quantum watermark system > > > > >=20 > > > > > Recovery Process > > > > >=20 > > > > > Recovery Timing Matrix > > > > >=20 > > > > > | Scenario | Timing | Method | Requirements | > > > > >=20 > > > > > |---------------------------|-------------------------------|----= -----------------------|----------------------------| > > > > >=20 > > > > > | M-Day (Migration Day) | Pre-Q-Day with Hard Fork | Consensus-ba= sed migration | Hard fork implementation | > > > > >=20 > > > > > | Q-Day (Quantum Day) | When quantum computers arrive | White-hat= recovery race | No protocol changes needed | > > > > >=20 > > > > > | Emergency Cut-over | Catastrophic quantum break | Parallel chai= n migration | Rapid consensus response | > > > > >=20 > > > > > | Overlapping M/Q-Day | Both processes active | Concurrent migrat= ions | Mempool competition | > > > > >=20 > > > > > Recovery Protocol > > > > >=20 > > > > > All recovery transactions follow the same pattern: > > > > >=20 > > > > > 1. Move vulnerable coins to protective custody addresses > > > > >=20 > > > > > 2. Leave OP_RETURN notification on original address with recovery= information > > > > >=20 > > > > > 3. Prioritize by dormant period and value at risk > > > > >=20 > > > > > 4. Quantum watermarks permit immediate return of funds > > > > >=20 > > > > > Consensus Layer > > > > >=20 > > > > > Implementation varies based on timing and consensus level (see Re= covery Timing Matrix above): > > > > >=20 > > > > > No Action: PQP (Post Quantum Pay) wallet technology - purely comm= ercial/user layer > > > > >=20 > > > > > Consensus: Community endorsement strengthens legal position for w= hite-hat recovery > > > > >=20 > > > > > Soft Fork: Taproot V2/BIP-360 enables voluntary migration (doesn'= t protect dormant accounts) > > > > >=20 > > > > > Hard Fork: Required for pre-Q-Day recovery or emergency cut-over = scenarios > > > > >=20 > > > > > Implementation Timeline > > > > >=20 > > > > > Phase 0: Launch - Live from Day One > > > > >=20 > > > > > - DAO Governance: Active voting on proposals from day one > > > > >=20 > > > > > - Initial Publication: Non-Sovereign Wealth Fund Proposal Discuss= ion > > > > >=20 > > > > > Phase 1: Consensus Building & Infrastructure (Months 1-6) > > > > >=20 > > > > > - Community discussion and refinement (while QD3 registrations co= ntinue) > > > > >=20 > > > > > - Technical specification development for advanced features > > > > >=20 > > > > > - Technical specification for backup chain > > > > >=20 > > > > > - Legal framework establishment with states > > > > >=20 > > > > > - Coordination with regulatory bodies for good-faith protections > > > > >=20 > > > > > - Signing the main quantum computer makers to the recovery princi= ples > > > > >=20 > > > > > - Begin backup chain development using post-quantum signature sch= emes (e.g., FIPS 204 ML-DSA) > > > > >=20 > > > > > Phase 2: Enhanced Infrastructure (Months 7-12) > > > > >=20 > > > > > - Smart contract deployment for fund management > > > > >=20 > > > > > - Advanced governance system implementation > > > > >=20 > > > > > - Claim verification protocol enhancements > > > > >=20 > > > > > - Complete backup chain synchronization and cut over process > > > > >=20 > > > > > - Multi-signature protective custody addresses pre-established > > > > >=20 > > > > > Phase 3: Recovery Preparation (Months 13-18) > > > > >=20 > > > > > - Public notification system deployment > > > > >=20 > > > > > - Recovery transaction staging > > > > >=20 > > > > > - Security audits of all systems > > > > >=20 > > > > > - Publish recovery chain software > > > > >=20 > > > > > - Public notice period initiation (6 months before recovery) > > > > >=20 > > > > > - Broadcast intent to recover specific UTXOs > > > > >=20 > > > > > - Allow time for unregistered owners to move coins or register cl= aims > > > > >=20 > > > > > - Publish recovery transactions in mempool but not mine > > > > >=20 > > > > > Phase 4: Active Recovery (Month 19+) > > > > >=20 > > > > > - Execute recovery per Recovery Timing Matrix > > > > >=20 > > > > > - Use Recovery Protocol for all transactions > > > > >=20 > > > > > - Manage protective custody with multi-signature addresses > > > > >=20 > > > > > - Process ownership claims per Claim Verification Protocol > > > > >=20 > > > > > - Initiate fund operations per Fund Architecture > > > > >=20 > > > > > Proposed Fund Architecture > > > > >=20 > > > > > +-----------------------------------------+ > > > > >=20 > > > > > | Recovered Bitcoin | > > > > >=20 > > > > > | (Principal - 100% Preserved) | > > > > >=20 > > > > > +-----------------------------------------+ > > > > >=20 > > > > > | > > > > >=20 > > > > > v > > > > >=20 > > > > > +-----------------------------------------+ > > > > >=20 > > > > > | Conservative Strategies | > > > > >=20 > > > > > | (3-5% Annual Return) | > > > > >=20 > > > > > | * Lightning Network Liquidity | > > > > >=20 > > > > > | * DeFi Lending Protocols | > > > > >=20 > > > > > | * Bitcoin-backed Stablecoins | > > > > >=20 > > > > > +-----------------------------------------+ > > > > >=20 > > > > > | > > > > >=20 > > > > > v > > > > >=20 > > > > > +-----------------------------------------+ > > > > >=20 > > > > > | Interest Distribution | > > > > >=20 > > > > > | (Public Good Only) | > > > > >=20 > > > > > | * Open Source Development | > > > > >=20 > > > > > | * Quantum Security Research | > > > > >=20 > > > > > | * Global Infrastructure | > > > > >=20 > > > > > | * AI Safety & Alignment | > > > > >=20 > > > > > +-----------------------------------------+ > > > > >=20 > > > > > Claim Verification Protocol > > > > >=20 > > > > > Original owners can reclaim their coins at ANY time by providing: > > > > >=20 > > > > > Prior to Break (Q-Day): > > > > >=20 > > > > > 1. Cryptographic Proof: Message signed with their key > > > > >=20 > > > > > 2. Optional Supporting Evidence: Transaction history, temporal pa= tterns if there is any doubt/dispute on Q-Day date > > > > >=20 > > > > > Post Break: > > > > >=20 > > > > > 1. Identity Verification: Since quantum computers will create pub= licly available databases of all exposed private keys (similar to existing = databases of classically compromised keys), possession of the private key a= lone is insufficient. > > > > >=20 > > > > > 2. Required Evidence: > > > > >=20 > > > > > - government-issued identification > > > > >=20 > > > > > - Historical transaction knowledge > > > > >=20 > > > > > - Temporal pattern matching > > > > >=20 > > > > > - Social recovery attestations > > > > >=20 > > > > > This approach recognizes that post-quantum, private key possessio= n becomes meaningless as proof of ownership since quantum-derived key datab= ases will be publicly available. > > > > >=20 > > > > > Three-tier Evidence Hierarchy > > > > >=20 > > > > > The claim verification process employs a three-tier evidence hier= archy to evaluate ownership claims with staking and slashing to prevent fra= ud and partial time based awards in case of partial proof. Evidence strengt= h: > > > > >=20 > > > > > - Tier 1: Cryptographic proofs with verifiable pre-break timestam= ps (signatures in pre-quantum blocks and similar immutable records) > > > > >=20 > > > > > - Tier 2: Third-party records (exchange logs, bankruptcy filings,= probate rulings, trustee statements) > > > > >=20 > > > > > - Tier 3: Supporting materials (affidavits, chain-of-inheritance,= media coverage, witness declarations) > > > > >=20 > > > > > Governance Structure > > > > >=20 > > > > > The QSAVE fund requires robust decentralized governance to ensure= proper stewardship of recovered assets. The governance framework must bala= nce efficiency with decentralization while maintaining absolute commitment = to principal preservation. > > > > >=20 > > > > > Core Governance Principles: > > > > >=20 > > > > > - Quadratic Voting: Reduces influence of large stakeholders while= maintaining democratic participation > > > > >=20 > > > > > - Multi-Council Structure: Separates technical, allocation, and a= udit functions to prevent capture > > > > >=20 > > > > > - Constraints: Only generated returns may be allocated (per princ= iple #1) > > > > >=20 > > > > > - Emergency Procedures: Supermajority (75%) required for emergenc= y actions; freeze of recovery process can be executed by authorized individ= uals until quarum can be established. > > > > >=20 > > > > > Governance Bodies: > > > > >=20 > > > > > - Technical Council: Oversees security, recovery operations, and = technical infrastructure > > > > >=20 > > > > > - Allocation Council: Manages distribution of generated returns t= o for the public good thru charitable donation, impact investing or researc= h funding. > > > > >=20 > > > > > - Audit Council: Provides independent oversight and transparency = reporting > > > > >=20 > > > > > Safeguards: > > > > >=20 > > > > > - Staggered terms to ensure continuity > > > > >=20 > > > > > - Public transparency of all decisions > > > > >=20 > > > > > - Time-locked implementations for non-emergency changes > > > > >=20 > > > > > - Immutable smart contracts for principal preservation > > > > >=20 > > > > > Rationale > > > > >=20 > > > > > The QSAVE protocol represents the optimal technical implementatio= n for addressing quantum vulnerability. Unlike binary approaches (burn or a= llow appropriation), QSAVE introduces a third path that aligns with Bitcoin= 's core principles while solving practical challenges. > > > > >=20 > > > > > Technical Neutrality > > > > >=20 > > > > > QSAVE maintains implementation flexibility: > > > > >=20 > > > > > - Fork-neutral: Works with or without protocol changes (see Recov= ery Timing Matrix) > > > > >=20 > > > > > - Price-neutral: Markets have already priced quantum risk (per Bl= ackRock ETF disclosures) > > > > >=20 > > > > > - Liquidity-neutral: Principal preservation prevents market disru= ption > > > > >=20 > > > > > Implementation Advantages > > > > >=20 > > > > > - Transparent Operations: All movements follow Recovery Protocol > > > > >=20 > > > > > - Decentralized Governance: See Governance Structure section > > > > >=20 > > > > > - Auditable Recovery: See Claim Verification Protocol > > > > >=20 > > > > > - Progressive Deployment: Phase 0 operational from day one > > > > >=20 > > > > > Risk Mitigation > > > > >=20 > > > > > The protocol addresses key operational risks: > > > > >=20 > > > > > - Race Condition Risk: Pre-positioned infrastructure for rapid Q-= Day response > > > > >=20 > > > > > - Legal Clarity: Aligns with established lost & found precedents > > > > >=20 > > > > > - Governance Capture: Quadratic voting and mandatory principal pr= eservation constraints > > > > >=20 > > > > > - Technical Failure: Backup chain with post-quantum signatures en= sures continuity > > > > >=20 > > > > > Legal Framework Considerations > > > > >=20 > > > > > The recovery process aligns with established legal principles in = many jurisdictions. Under precedents like People v. Jennings (NY 1986), tem= porary custody without intent to permanently deprive does not constitute la= rceny. This is analogous to moving lost property to a lost & found =E2=80= =94 a universally accepted practice despite technically involving "taking w= ithout permission." > > > > >=20 > > > > > In the United States alone, over 400 million items are moved to l= ost & found departments annually without legal consequence. QSAVE applies t= his same principle to digital assets vulnerable to quantum attack, providin= g a protective custody mechanism that preserves ownership rights. > > > > >=20 > > > > > Furthermore, the U.S. Department of Justice's policy on good-fait= h security research provides additional legal clarity for recovery operator= s acting to protect vulnerable assets from quantum threats. > > > > >=20 > > > > > Legal clarification and Jurisdiction choices need to be made. > > > > >=20 > > > > > The Sovereign Law Paradox > > > > >=20 > > > > > Without protective frameworks, law-abiding states face a critical= disadvantage. Bad actors operating from jurisdictions with weak or non-exi= stent cryptocurrency regulations can exploit quantum vulnerabilities with i= mpunity, while good-faith actors in law-compliant states remain paralyzed b= y legal uncertainty. This creates a systematic wealth transfer from citizen= s of law-abiding nations to criminal organizations and rogue states. The st= rongest property laws paradoxically create the weakest defense against quan= tum theft. Jurisdictions are developing good faith exemptions to their comp= uter security laws and these will need to accelerate. > > > > >=20 > > > > > Economic Impact > > > > >=20 > > > > > Positive Effects > > > > >=20 > > > > > - Removes quantum uncertainty from Bitcoin price > > > > >=20 > > > > > - Funds public good without inflation or taxation (see Fund Archi= tecture) > > > > >=20 > > > > > - Preserves Bitcoin's fixed supply economics (Principle #1) > > > > >=20 > > > > > - Creates new model for decentralized capital allocation > > > > >=20 > > > > > Neutral Effects > > > > >=20 > > > > > - No net change in circulating supply (coins preserved, not spent= ) > > > > >=20 > > > > > - Market has already priced in quantum risk per BlackRock ETF ter= ms > > > > >=20 > > > > > - Interest generation creates minimal selling pressure > > > > >=20 > > > > > Appendix: Quantum Vulnerability > > > > >=20 > > > > > Vulnerable Address Categories > > > > >=20 > > > > > | Category | Address Type | Key Status | Quantum Vulnerable | Est= . BTC (M) | Recovery Priority | Notes | > > > > >=20 > > > > > |-----------------------|------------------|------------|--------= ------------|--------------|-------------------|---------------------------= ---------| > > > > >=20 > > > > > | P2PK Outputs | P2PK | Various | Yes | 1.9-2.0 | Critical | Dire= ctly exposed public keys | > > > > >=20 > > > > > | Taproot (All) | P2TR | Various | Yes | 0.5-1 | Critical | ALL T= aproot addresses exposed | > > > > >=20 > > > > > | Reused P2PKH (spent) | P2PKH | Various | Yes | 2-4 | High | Spe= nt =3D pubkey revealed | > > > > >=20 > > > > > | Reused P2WPKH (spent) | P2WPKH | Various | Yes | ~0.5-1 | High = | Modern but still vulnerable | > > > > >=20 > > > > > | Unused P2PKH | P2PKH | Various | No | 6-8 | Protected | Hash on= ly; quantum-safe | > > > > >=20 > > > > > | Unused P2WPKH | P2WPKH | Various | No | 4-6 | Protected | Moder= n safe until spent | > > > > >=20 > > > > > | Script Hash | P2SH/P2WSH | Various | Mostly No | 3-4 | Protecte= d | Generally safe (depends on script) | > > > > >=20 > > > > > | Total Vulnerable | | | Yes | 3.5-5.5M | | 17-28% of supply | > > > > >=20 > > > > > Quantum Risk > > > > >=20 > > > > > There is a lack of consensus on the timeline for the quantum thre= at other than it appears to be accelerating: > > > > >=20 > > > > > Expert Consensus: > > > > >=20 > > > > > - Conservative estimates (NIST IR 8413): 2035-2050 > > > > >=20 > > > > > - Aggressive projections: 2027-2035 > > > > >=20 > > > > > - Industry leaders (including Brock Pierce at Tokenize 2025): "Ye= s, quantum was 20 years away until recently. It's likely this decade. Most = people are now pinpointing it at 2027. I think that's early, but there's so= me bright minds working on it." > > > > >=20 > > > > > Recent Technical Advances: > > > > >=20 > > > > > - Google's 2025 research: Demonstrated that 2048-bit RSA encrypti= on could theoretically be broken by a quantum computer with 1 million noisy= qubits running for one week (20-fold decrease from previous estimate) > > > > >=20 > > > > > - Jensen Huang (NVIDIA CEO): Shifted to optimistic stance, statin= g quantum computing is "reaching an inflection point" and we're "within rea= ch of being able to apply quantum computing" to solve problems "in the comi= ng years" > > > > >=20 > > > > > Regulatory Requirements: > > > > >=20 > > > > > - U.S. National Security Systems must use quantum-resistant algor= ithms for new acquisitions after January 1, 2027 (NSA CNSA 2.0) > > > > >=20 > > > > > - Given 1-5 year government procurement cycles, blockchain propos= als today must be quantum-proof > > > > >=20 > > > > > References > > > > >=20 > > > > > 1. NIST IR 8413 - "Status Report on the Third Round of the NIST P= ost-Quantum Cryptography Standardization Process", July 2022. > > > > >=20 > > > > > https://doi.org/10.6028/NIST.IR.8413 > > > > >=20 > > > > > 2. NSA CNSA 2.0 - "Commercial National Security Algorithm Suite 2= .0 FAQ", September 7, 2022. > > > > >=20 > > > > > https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA= _2.0_FAQ_.PDF > > > > >=20 > > > > > 3. Google Quantum AI - "Quantum Advantage in Error Correction", N= ature, 2025. > > > > >=20 > > > > > Demonstrated 99.85% reduction in required quantum resources. > > > > >=20 > > > > > 4. Jensen Huang - "Nvidia CEO says quantum computing is at an inf= lection point", Channel News Asia, June 11, 2025. > > > > >=20 > > > > > https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-= computing-inflection-point-5174861 > > > > >=20 > > > > > 5. Global Risk Institute - "Quantum Threat Timeline 2025: Executi= ve Perspectives on Barriers to Action", 2025. > > > > >=20 > > > > > https://globalriskinstitute.org/publication/quantum-threat-timeli= ne-2025-executive-perspectives-on-barriers-to-action/ > > > > >=20 > > > > > 6. Brock Pierce - "Million Dollar Bitcoin CONFIRMED! Brock Pierce= & Michael Terpin Drop BOMBS at Tokenize! 2025." YouTube, timestamp 18:10. > > > > >=20 > > > > > https://www.youtube.com/watch?v=3DDhYO1Jxmano > > > > >=20 > > > > > 7. Satoshi Nakamoto - BitcoinTalk Forum post, 2010. "If it happen= s gradually, we can transition to something stronger." > > > > >=20 > > > > > https://bitcointalk.org/index.php?topic=3D3120.0 > > > > >=20 > > > > > 8. FIPS 204 - "Module-Lattice-Based Digital Signature Standard", = August 2024. > > > > >=20 > > > > > Specifies CRYSTALS-Dilithium (ML-DSA). > > > > >=20 > > > > > 9. BIP 341 - "Taproot: SegWit version 1 spending rules", January = 2020. > > > > >=20 > > > > > https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki > > > > >=20 > > > > > 10. BlackRock iShares Bitcoin Trust - Prospectus acknowledging qu= antum computing risk to Bitcoin holdings, 2024. > > > > >=20 > > > > > 11. Mosca, M. - "Quantum Threat Timeline," University of Waterloo= , 2023. > > > > >=20 > > > > > Estimates 2035-2040 timeline for quantum threats to cryptography. >=20 > -- > You received this message because you are subscribed to a topic in the Go= ogle Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/b= itcoindev/PjpaidcHX4A/unsubscribe. > To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/e4c8c8e8-0ffe-42a6-905a-0859b2123f73n%40googlegroups.com. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= DAMggb_d_6zYhiF_FlsncyRWtISna4vwLVh7xzLfCC4LE0IfMnYCJfwDYOqN_zRli44uGkvHIDL= mVebrVExgSK7xsjWfFj0laaCK7V530QQ%3D%40proton.me. -----------------------92c15b7d3d80cb94fc64e34e98353c5f Content-Type: multipart/related;boundary=---------------------ade8450dd85a46e61b41df6f00ee53c5 -----------------------ade8450dd85a46e61b41df6f00ee53c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi James,

Notice h= ow satoshi is talking about replacing the hash function SHA256 in the conte= xt of blocks and proof-of-work, and that if SHA256 is broken we could walk = the chain back a bit and then "continue from there with a new hash function= ". He's saying the community can come to consensus on a new hash algo and then nodes continue operating under the same decentralized PoW p= rotocol from then onwards, just with a slightly cryptographic primitive und= erlying it.

He is most definitely not saying the community should vest= the power to mint new blocks in some trusted block-producing organization.= That would be more closely analogous to what QSAVE is proposing, and would= likewise be a total reversal of the principles that Bitcoin was founded on= .

Unfortunately, a consensus hash algorithm switcheroo is muc= h easier to engineer than migrating the UTXO set to a new PQ secure signing= primitive, because with UTXOs we're talking about an authentication (owner= ship) problem, rather than a coordination (consensus) problem. As you know,= the network can't just hot-swap signing algorithms for old UTXOs the = same way we can hot-swap hash algorithms for new blocks.

For the curious, here= is the original thread where Satoshi said these things. https://bitcointalk.org/index.php?topic=3D191.0<= /a>

regards,<= /div>
condui= tion
On Friday, September 5th, 2025 at 9:45 AM, 'James T' via Bitcoin De= velopment Mailing List <bitcoindev@googlegroups.com> wrote:
=20

If we are going to quote Satoshi, he imagined that some group of peo= ple=E2=80=94the consensus=E2=80=94could come together and agree on what the= chain should say if the underlying maths failed. =E2=80=9CIf SHA-256 becam= e completely broken, I think we could come to some agreement about what the= honest blockchain was before the trouble started, lock that in, and contin= ue from there with a new hash function.=E2=80=9D

This is exactly what I am proposing; that we come to some agreement a= bout what the honest blockchain. If ECSDA is compromised, the only way to f= ix it will be to reach a consensus, and that will require the labor of peop= le.

So far from being a non-negotiable point, this was anticipate= d from the beginning. I do agree with the sentiment. It would be great to h= ave a protocol that operated independently of any human involvement but, th= e very fact that we are having this debate means we are past that point. We= will have to decide which path to take and I think the QSAVE proposal does= the least harm and the most good.

Best,

James


On Tuesday, August= 19, 2025 at 3:54:01=E2=80=AFAM UTC-7 Javier Mateos wrote:
Hi James, thanks for opening t= his discussion.

One point that is non-negotiable in Bitc= oin is "embedding" in the code a group of people to arbitrate claims. That = goes against de very essence of the network ("trustless") and was part of t= he reason Bitcoin was created.

While not strictly = canonical from Satoshi, his messages are clear: "what is needed is an elect= ronic payment system based on cryptographic proof instead of trust..." and = "lost coins only make everyone else's coins worth slightly more..." Coin lo= ss is an inherent risk of the system, but that shouldn=C2=B4t be confused w= ith designing a protocol that automatically protects funds and transactions= via human arbiters.

That's why I consider this (and other) d= ebates about preparing Bitcoin to survive in a potentially dangerous quantu= m enviroment valid, whether that happens in 5 years or 100. Sooner or later= , upgrades will be needeed, but the response must be technical and opt-in (= migration to post-quantum signatures, inheritable vaults, voluntary mechani= sms), not a return to introducing judges into consensus.

Best regar= ds,
Javier Mateos

El lunes, 18 de agosto de 2025 a las 14= :12:36 UTC-3, James T escribi=C3=B3:
I am suggesting that Bitcoin elects people who c= an arbitrate reasonable claims. The Bitcoin dev team proposing a burn solut= ion is the same problem you articulate: a small group of people (80% of min= ers) voting to burn coins. I don't see a way around this fundamental proble= m. The keys will fail in the future; some human intervention is going to ha= ppen. Remember, if the burn happens, tens of thousands of people will open = safety deposit boxes full of Bitcoin addresses and find them zeroed out. On= ly our solution provides a solution to this and preserves the Digital Gold = promise.

We like to assume there is no human inter= vention in Bitcoin and it's all algorithmic, but that's not true. There is = an army of people working to secure Bitcoin behind the scenes, including up= front KYC/AML and after-the-fact recovery by private companies and law enfo= rcement when there is a hack. This all works on a worldwide basis today.

No lawyers have been involved in the drafting of our= proposal. I would welcome input, but it's really an engineering problem. O= nce Bitcoin keys can no longer be relied on, what do we do to establish own= ership? Deleting ownership is certainly one solution, but I just don't thin= k it is a fair one.

We are proposing our solution = as either a hard fork or a no-fork. Either way, we still have to solve the = problem of a room full of elected experts to adjudicate claims (obviously, = they would be distributed worldwide, and often it could be achieved algorit= hmically).

In the no-fork solution, we encourage -= maybe reward - white hat quantum actors to recover vulnerable Bitcoin unde= r lost property law. If it's claimed, then it's returned; if not claimed, i= t's invested for the public good. This is then a race between white hat and= black hat actors. BUT most laws will deter white hat actors because it mig= ht be considered computer misuse. It would be really helpful if the Bitcoin= consensus said, "We favor white hat actors protecting Bitcoin". Although t= here are no Bitcoin terms and conditions or EULA, this would massively prot= ect white hats.

In the hard fork solution, instead= of burning the coins, they go into the recovery process, and here the Bitc= oin consensus has made a clear protocol decision, and there is no white hat= actor risk.

I apologize for the lack of technical= details at this point. We have a lot of code written, and I did make a not= e to that effect in my submission, but that bit seems to have been cut off.= The recovery process has to obey the law and be distributable worldwide, a= nd be fair, and I think it is possible to do all that. Not simple, of cours= e. In the meantime, there are plenty of best practices that can be implemen= ted to better protect and prepare the network, which I know are in process.=

Best,


Jam= es T


On Friday, August 8, 2025 at 7:07:25=E2=80=AFPM UTC-7 c= onduition wrote:
Hi Ja= mes,

This is a curious idea, though I'm not seeing any t= echnical details of how this "BIP" would maintain Bitcoin's value as a dist= ributed system. It more-or-less sounds like you're suggesting to vest the p= ower of quantum-recovery using legal mechanisms (e.g. KYC, real-world evide= nce, etc)... in a group of people working in an office somewhere? Surely yo= u realize that's impractical and un-scaleable. Besides, even if you had all= the manpower needed to do it, no one who owns Bitcoin would run a node whi= ch subscribes to such consensus rules. A huge portion of the supply on that= (hardforked) chain would be effectively under the total control of a selec= t few. Who elects these people?

It sounds like som= ething a corporate lawyer would cook up if asked how to solve the post-quan= tum-rescue problem. Not to say that legal opinions on quantum migration are= unwanted. I'm sure there are interesting legal questions to be debated aro= und the rights of property holders in case of a possible quantum-freeze. Bu= t this proposal at least is DOA because KYC cannot be the answer, fo= r practical and ethical reasons.

Perhaps, independ= ent of any technical consensus upgrades, it would be wise to encourage quan= tum adversaries to become benevolent, somehow. I'm not sure what that looks= like. If a quantum freeze doesn't happen, there ought to be legal guidelin= es for how quantum giants like Google or IBM should behave given their newf= ound quantum weaponry. It'll be impossible to fully enforce any such rules,= but if they want to play nice, someone should tell them what "playi= ng nice" actually looks like.

regards,
c= onduition
On Thursday, August 7, 2025 at 5:26:07=E2=80=AFPM UTC-7 James T wrote= :

This BIP Proposal i= s an alternative to QRAMP or a quantum winner-takes-all approach to the mig= ration from a pre- to post quantum blockchain. It could be implemented as a= hard fork OR as a consensus that quantum actors can legitimately move funds to safe addresses for protective custod= y and public good. It could even go forward with no consensuses at all sinc= e it is functionally equivalent to a quantum winner-takes-all at the protoc= ol level.

BIP: TBD<= /u>

Title: Quantum Secu= re Asset Verification & Escrow (QSAVE)

Author: James Tagg =

Status: Draft

Type: Standards Tra= ck

Layer: Consensus (C= onsensus / Soft Fork / Hard Fork)

Created:<= /u>

License: =

Abstract<= /u>

This BIP proposes Q= SAVE (Quantum Secure Asset Verification & Escrow) - a non-sovereign wea= lth fund providing protective custody for Bitcoin vulnerable to quantum att= ack (see Appendix for detailed vulnerability assessment). QSAVE preserves 100% of the principal for rightful owners whi= le using generated returns to fund the protocol and global public good. It = provides an alternative to the QRAMP (Quantum Resistant Asset Migration Pro= tocol) proposal (which makes coins unspendable) or taking no action (which allows quantum appropriation, whic= h many view as theft). This proposal addresses coins that are dormant but a= cknowledges there may be coins that have quantum watermarks but have not mi= grated to quantum addresses. A separate BIP proposal will address this case.

Motivation

Chain analysis reve= als 3.5-5.5 million Bitcoin (~17-28% of circulating supply) have exposed pu= blic keys vulnerable to quantum attack (see Appendix: Quantum Vulnerability= Assessment for detailed breakdown).

With sufficient edu= cation and proactive migration, a significant portion of the 2-4M BTC in re= used addresses could be moved to quantum-safe addresses before the threat m= aterializes. Modern wallets are increasingly implementing best practices such as always sending change to fresh address= es. However, some portion will inevitably remain unprotected when quantum c= omputers arrive due to:

- Owners who don't = follow Bitcoin news

- Forgotten wallets= discovered years later

- Cold storage assu= med long term safe

- Users who die and= whose heirs have yet to uncover the keys

- Users who procras= tinate or underestimate the threat

When quantum comput= ers capable of running Shor's algorithm arrive, the remaining vulnerable co= ins face two equally problematic outcomes:

1. Quantum appropri= ation: First actors with quantum computers take the coins

2. Forced burning: = The community burns coins preventatively (by making them unspendable), brea= king Bitcoin's promise as a store of value

This BIP proposes a= third way: QSAVE - protective custody that preserves ownership rights and = puts dormant capital to work for humanity.

Note on "Theft": Bi= tcoin's protocol operates purely through cryptographic proofs, without buil= t-in concepts of ownership or theft=E2=80=94these are legal constructs that= vary by jurisdiction. The community holds divergent views: some consider using advanced technology to derive private keys as l= egitimate within Bitcoin's rules, while others view it as unethical appropr= iation of others' funds.

QSAVE addresses bot= h perspectives: If quantum key derivation is considered fair game, then rac= ing to secure vulnerable coins before malicious actors is simply good-faith= participation in the system. If it's deemed unethical, then the community needs a consensus solution that balan= ces property rights with Bitcoin's algorithmic nature. Either way, protecti= ve custody preserves coins for their rightful owners rather than allowing t= hem to be stolen or destroyed.

The Inheritance Vul= nerability Window

Consider the "Aunti= e Alice's Bitcoin" scenario: Alice stores Bitcoin in cold storage as inheri= tance for her grandchildren, with keys secured in a safe deposit box. She d= oesn't follow Bitcoin news and remains unaware of quantum threats. She passes away and by the time her heirs disc= over the wallet, quantum computers capable of deriving private keys have em= erged.

Three outcomes are = possible:

1. Without protecti= on: Quantum actors take the grandchildren's inheritance

2. With burning: Th= e network destroys legitimate inheritance funds

3. With protective = custody: Heirs can claim their inheritance with proper evidence (will, keys= , proof of box opening)

This illustrates wh= y we cannot assume dormant equals lost and why protective custody is the on= ly approach that preserves legitimate ownership rights. The inability to di= stinguish between lost coins and stored coins is the fundamental reason protective custody is essential.=

Principles

1. Preserve the pri= ncipal - 100% of recovered Bitcoin remains available for rightful owners to= reclaim at any time

2. Ensure long-term= store of value by avoiding any pre-emptive burn (making coins unspendable)=

3. Avoid market sho= cks by keeping principal locked while only using generated returns

4. Generate returns= for the benefit of humanity through conservative yield strategies

5. Protect the Chai= n, ensuring smooth transition to post-quantum era

6. Enable priority = recovery through quantum watermark system

Recovery Process=

Recovery Timing Mat= rix

| Scenario = | Timing | Method | Requ= irements |

|------------------= ---------|-------------------------------|---------------------------|-----= -----------------------|

| M-Day (Migration = Day) | Pre-Q-Day with Hard Fork | Consensus-based migration | Hard= fork implementation |

| Q-Day (Quantum Da= y) | When quantum computers arrive | White-hat recovery race | No p= rotocol changes needed |

| Emergency Cut-ove= r | Catastrophic quantum break | Parallel chain migration | Rapi= d consensus response |

| Overlapping M/Q-D= ay | Both processes active | Concurrent migrations | Memp= ool competition |

Recovery Protocol

All recovery transa= ctions follow the same pattern:

1. Move vulnerable = coins to protective custody addresses

2. Leave OP_RETURN = notification on original address with recovery information

3. Prioritize by do= rmant period and value at risk

4. Quantum watermar= ks permit immediate return of funds

Consensus Layer<= /u>

Implementation vari= es based on timing and consensus level (see Recovery Timing Matrix above):<= u>

No Action: PQP (Pos= t Quantum Pay) wallet technology - purely commercial/user layer

Consensus: Communit= y endorsement strengthens legal position for white-hat recovery

Soft Fork: Taproot = V2/BIP-360 enables voluntary migration (doesn't protect dormant accounts)

Hard Fork: Required= for pre-Q-Day recovery or emergency cut-over scenarios

Implementation Time= line

Phase 0: Launch - L= ive from Day One

- DAO Governance: A= ctive voting on proposals from day one

- Initial Publicati= on: Non-Sovereign Wealth Fund Proposal Discussion

Phase 1: Consensus = Building & Infrastructure (Months 1-6)

- Community discuss= ion and refinement (while QD3 registrations continue)<= /p>

- Technical specifi= cation development for advanced features

- Technical specifi= cation for backup chain

- Legal framework e= stablishment with states

- Coordination with= regulatory bodies for good-faith protections

- Signing the main = quantum computer makers to the recovery principles

- Begin backup chai= n development using post-quantum signature schemes (e.g., FIPS 204 ML-DSA)<= u>

Phase 2: Enhanced I= nfrastructure (Months 7-12)

- Smart contract de= ployment for fund management

- Advanced governan= ce system implementation

- Claim verificatio= n protocol enhancements

- Complete backup c= hain synchronization and cut over process

- Multi-signature p= rotective custody addresses pre-established

Phase 3: Recovery P= reparation (Months 13-18)

- Public notificati= on system deployment

- Recovery transact= ion staging

- Security audits o= f all systems

- Publish recovery = chain software

- Public notice per= iod initiation (6 months before recovery)

- Broadcast inten= t to recover specific UTXOs

- Allow time for = unregistered owners to move coins or register claims

- Publish recover= y transactions in mempool but not mine

Phase 4: Active Rec= overy (Month 19+)

- Execute recovery = per Recovery Timing Matrix

- Use Recovery Prot= ocol for all transactions

- Manage protective= custody with multi-signature addresses

- Process ownership= claims per Claim Verification Protocol

- Initiate fund ope= rations per Fund Architecture

Proposed Fund Archi= tecture

+------------------= -----------------------+

| Recovere= d Bitcoin |

| (Principal -= 100% Preserved) |

+------------------= -----------------------+

|<= u>

v<= u>

+------------------= -----------------------+

| Conservati= ve Strategies |

| (3-5% Annu= al Return) |

| * Lightning N= etwork Liquidity |

| * DeFi Lendin= g Protocols |

| * Bitcoin-bac= ked Stablecoins |

+------------------= -----------------------+

|<= u>

v<= u>

+------------------= -----------------------+

| Interest = Distribution |

| (Public G= ood Only) |

| * Open Source= Development |

| * Quantum Sec= urity Research |

| * Global Infr= astructure |

| * AI Safety &= amp; Alignment |

+------------------= -----------------------+

Claim Verification = Protocol

Original owners can= reclaim their coins at ANY time by providing:

Prior to Break (Q-D= ay):

1. Cryptographic Pr= oof: Message signed with their key

2. Optional Support= ing Evidence: Transaction history, temporal patterns if there is any doubt/= dispute on Q-Day date

Post Break:<= u>

1. Identity Verific= ation: Since quantum computers will create publicly available databases of = all exposed private keys (similar to existing databases of classically comp= romised keys), possession of the private key alone is insufficient.

2. Required Evidenc= e:

- government-iss= ued identification

- Historical tra= nsaction knowledge

- Temporal patte= rn matching

- Social recover= y attestations

This approach recog= nizes that post-quantum, private key possession becomes meaningless as proo= f of ownership since quantum-derived key databases will be publicly availab= le.

Three-tier Evidence= Hierarchy

The claim verificat= ion process employs a three-tier evidence hierarchy to evaluate ownership c= laims with staking and slashing to prevent fraud and partial time based awa= rds in case of partial proof. Evidence strength:

- Tier 1: Cryptogra= phic proofs with verifiable pre-break timestamps (signatures in pre-quantum= blocks and similar immutable records)

- Tier 2: Third-par= ty records (exchange logs, bankruptcy filings, probate rulings, trustee sta= tements)

- Tier 3: Supportin= g materials (affidavits, chain-of-inheritance, media coverage, witness decl= arations)

Governance Structur= e

The QSAVE fund requ= ires robust decentralized governance to ensure proper stewardship of recove= red assets. The governance framework must balance efficiency with decentral= ization while maintaining absolute commitment to principal preservation.

Core Governance Pri= nciples:

- Quadratic Voting:= Reduces influence of large stakeholders while maintaining democratic parti= cipation

- Multi-Council Str= ucture: Separates technical, allocation, and audit functions to prevent cap= ture

- Constraints: Only= generated returns may be allocated (per principle #1)=

- Emergency Procedu= res: Supermajority (75%) required for emergency actions; freeze of recovery= process can be executed by authorized individuals until quarum can be esta= blished.

Governance Bodies:<= u>

- Technical Council= : Oversees security, recovery operations, and technical infrastructure

- Allocation Counci= l: Manages distribution of generated returns to for the public good thru ch= aritable donation, impact investing or research funding.

- Audit Council: Pr= ovides independent oversight and transparency reporting

Safeguards:<= u>

- Staggered terms t= o ensure continuity

- Public transparen= cy of all decisions

- Time-locked imple= mentations for non-emergency changes

- Immutable smart c= ontracts for principal preservation

Rationale=

The QSAVE protocol = represents the optimal technical implementation for addressing quantum vuln= erability. Unlike binary approaches (burn or allow appropriation), QSAVE in= troduces a third path that aligns with Bitcoin's core principles while solving practical challenges.

Technical Neutralit= y

QSAVE maintains imp= lementation flexibility:

- Fork-neutral: Wor= ks with or without protocol changes (see Recovery Timing Matrix)<= /u>

- Price-neutral: Ma= rkets have already priced quantum risk (per BlackRock ETF disclosures)

- Liquidity-neutral= : Principal preservation prevents market disruption

Implementation Adva= ntages

- Transparent Opera= tions: All movements follow Recovery Protocol

- Decentralized Gov= ernance: See Governance Structure section

- Auditable Recover= y: See Claim Verification Protocol

- Progressive Deplo= yment: Phase 0 operational from day one

Risk Mitigation<= /u>

The protocol addres= ses key operational risks:

- Race Condition Ri= sk: Pre-positioned infrastructure for rapid Q-Day response

- Legal Clarity: Al= igns with established lost & found precedents

- Governance Captur= e: Quadratic voting and mandatory principal preservation constraints=

- Technical Failure= : Backup chain with post-quantum signatures ensures continuity

Legal Framework Con= siderations

The recovery proces= s aligns with established legal principles in many jurisdictions. Under pre= cedents like People v. Jennings (NY 1986), temporary custody without intent= to permanently deprive does not constitute larceny. This is analogous to moving lost property to a lost & found = =E2=80=94 a universally accepted practice despite technically involving "ta= king without permission."

In the United State= s alone, over 400 million items are moved to lost & found departments a= nnually without legal consequence. QSAVE applies this same principle to dig= ital assets vulnerable to quantum attack, providing a protective custody mechanism that preserves ownership rights.<= u>

Furthermore, the U.= S. Department of Justice's policy on good-faith security research provides = additional legal clarity for recovery operators acting to protect vulnerabl= e assets from quantum threats.

Legal clarification= and Jurisdiction choices need to be made.

The Sovereign Law P= aradox

Without protective = frameworks, law-abiding states face a critical disadvantage. Bad actors ope= rating from jurisdictions with weak or non-existent cryptocurrency regulati= ons can exploit quantum vulnerabilities with impunity, while good-faith actors in law-compliant states remain para= lyzed by legal uncertainty. This creates a systematic wealth transfer from = citizens of law-abiding nations to criminal organizations and rogue states.= The strongest property laws paradoxically create the weakest defense against quantum theft. Jurisdictions are develo= ping good faith exemptions to their computer security laws and these will n= eed to accelerate.

Economic Impact<= /u>

Positive Effects=

- Removes quantum u= ncertainty from Bitcoin price

- Funds public good= without inflation or taxation (see Fund Architecture)=

- Preserves Bitcoin= 's fixed supply economics (Principle #1)

- Creates new model= for decentralized capital allocation

Neutral Effects<= /u>

- No net change in = circulating supply (coins preserved, not spent)

- Market has alread= y priced in quantum risk per BlackRock ETF terms

- Interest generati= on creates minimal selling pressure

Appendix: Quantum V= ulnerability

Vulnerable Address = Categories

| Category = | Address Type | Key Status | Quantum Vulnerable | Est. BTC (M) | = Recovery Priority | Notes |

|------------------= -----|------------------|------------|--------------------|--------------|-= ------------------|------------------------------------|

| P2PK Outputs = | P2PK | Various | Yes | 1.9-2.0 | = Critical | Directly exposed public keys |

| Taproot (All) = | P2TR | Various | Yes | 0.5-1 | = Critical | ALL Taproot addresses exposed |

| Reused P2PKH (spe= nt) | P2PKH | Various | Yes | 2-4 | = High | Spent =3D pubkey revealed |

| Reused P2WPKH (sp= ent) | P2WPKH | Various | Yes | ~0.5-1 | = High | Modern but still vulnerable |

| Unused P2PKH = | P2PKH | Various | No | 6-8 | = Protected | Hash only; quantum-safe |

| Unused P2WPKH = | P2WPKH | Various | No | 4-6 | = Protected | Modern safe until spent |

| Script Hash = | P2SH/P2WSH | Various | Mostly No | 3-4 | = Protected | Generally safe (depends on script) |

| Total Vulnerable = | | | Yes | 3.5-5.5M | = | 17-28% of supply |

Quantum Risk=

There is a lack of = consensus on the timeline for the quantum threat other than it appears to b= e accelerating:

Expert Consensus:

- Conservative esti= mates (NIST IR 8413): 2035-2050

- Aggressive projec= tions: 2027-2035

- Industry leaders = (including Brock Pierce at Tokenize 2025): "Yes, quantum was 20 years away = until recently. It's likely this decade. Most people are now pinpointing it= at 2027. I think that's early, but there's some bright minds working on it."

Recent Technical Ad= vances:

- Google's 2025 res= earch: Demonstrated that 2048-bit RSA encryption could theoretically be bro= ken by a quantum computer with 1 million noisy qubits running for one week = (20-fold decrease from previous estimate)

- Jensen Huang (NVI= DIA CEO): Shifted to optimistic stance, stating quantum computing is "reach= ing an inflection point" and we're "within reach of being able to apply qua= ntum computing" to solve problems "in the coming years"

Regulatory Requirem= ents:

- U.S. National Sec= urity Systems must use quantum-resistant algorithms for new acquisitions af= ter January 1, 2027 (NSA CNSA 2.0)

- Given 1-5 year go= vernment procurement cycles, blockchain proposals today must be quantum-pro= of

References

1. NIST IR 8413 - "= Status Report on the Third Round of the NIST Post-Quantum Cryptography Stan= dardization Process", July 2022.

https://doi.org/10.6028/NIST.IR.8413

2. NSA CNSA 2.0 - "= Commercial National Security Algorithm Suite 2.0 FAQ", September 7, 2022.

https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.= PDF

3. Google Quantum A= I - "Quantum Advantage in Error Correction", Nature, 2025.

Demonstrated 99.= 85% reduction in required quantum resources.

4. Jensen Huang - "= Nvidia CEO says quantum computing is at an inflection point", Channel News = Asia, June 11, 2025.

https://www.channelnewsasia.com/business/nvidia-ceo-says-quantum-computing-= inflection-point-5174861

5. Global Risk Inst= itute - "Quantum Threat Timeline 2025: Executive Perspectives on Barriers t= o Action", 2025.

https://globalriskinstitute.org/publication/quantum-threat-timeline-2025-ex= ecutive-perspectives-on-barriers-to-action/

6. Brock Pierce - "= Million Dollar Bitcoin CONFIRMED! Brock Pierce & Michael Terpin Drop BO= MBS at Tokenize! 2025." YouTube, timestamp 18:10.

https://www.youtube.com/watch?v=3DDhYO1Jxmano

7. Satoshi Nakamoto= - BitcoinTalk Forum post, 2010. "If it happens gradually, we can transitio= n to something stronger."

https://bitcointalk.org/index.php?topic=3D3120.0

8. FIPS 204 - "Modu= le-Lattice-Based Digital Signature Standard", August 2024.

Specifies CRYSTA= LS-Dilithium (ML-DSA).

9. BIP 341 - "Tapro= ot: SegWit version 1 spending rules", January 2020.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

10. BlackRock iShar= es Bitcoin Trust - Prospectus acknowledging quantum computing risk to Bitco= in holdings, 2024.

11. Mosca, M. - "Qu= antum Threat Timeline," University of Waterloo, 2023.<= /p>

Estimates 2035-= 2040 timeline for quantum threats to cryptography.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/Pjpaid= cHX4A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/e4c8c8e8-0ffe-42a6-905a-0859b2123f73n%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/DAMggb= _d_6zYhiF_FlsncyRWtISna4vwLVh7xzLfCC4LE0IfMnYCJfwDYOqN_zRli44uGkvHIDLmVebrV= ExgSK7xsjWfFj0laaCK7V530QQ%3D%40proton.me.
-----------------------ade8450dd85a46e61b41df6f00ee53c5-- -----------------------92c15b7d3d80cb94fc64e34e98353c5f-- -----------------------0af7bc860dc3678ef701839f22a7fe4d Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------0af7bc860dc3678ef701839f22a7fe4d-- --------e5b0b37346044e40971b2484407204c706d57ee6dc0fb9c829cc85966aed03a1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmjIRFAJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdbx55H+Vw1QQfFLOn37O/2bI94nPNSE1f6YMxR X3fKWxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABVrQEA5pix8DKGkBuR3sEs 90csX5PQIn5eGhytBBwe4YDy0tgBAP7xrOZtb4kMYMf+2xwLJonBXmxafOM1 KCyhqR45tfcO =mWmp -----END PGP SIGNATURE----- --------e5b0b37346044e40971b2484407204c706d57ee6dc0fb9c829cc85966aed03a1--