From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Jul 2026 09:44:46 -0700 Received: from mail-ot1-f62.google.com ([209.85.210.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wjgFR-0007gZ-7v for bitcoindev@gnusha.org; Tue, 14 Jul 2026 09:44:45 -0700 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7ebfcb4c999sf6323604a34.1 for ; Tue, 14 Jul 2026 09:44:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1784047479; cv=pass; d=google.com; s=arc-20260327; b=Jo2BfYt9GAQJrfY171M6ak2jNuXI2d2RZdejFEnhWabeFB7KbMshO7RFeev1PlBgIh 7xKSKTqzmni0l9vxZ0Kb1VqO1Ll3p4DgtYKIyt2/rMR3W0UninL0JcAjsVImDLwcMdaD 4FS7VJ6Ziuh64FRK9JyLEEkft0ZICGM6QaCq5ra4AR/FF87++gSaX1rlH82iksGWFxbi Bm573GT8DfzVe+kZ6Asr8u1o7Cvi8sEQISWxXcT1ZyNsUUEDlYkcCr/tioL6kFUrKC6j 4+Z7aC+7CTi26kw5sfrG71NL/6ZJy5wucW5PKQ7bp2PNyd5m/6ZkvGJ8eB2VKpOUIn7q sinw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :message-id:subject:from:to:date:dkim-signature; bh=pKrPusGCEvTKym+1X9a7yRW4p9Nc5q1ix7fxfi73Bi4=; fh=TS1oyRBumpkuy2AaPDMACRTOOe8gJU3hdkWvBnr/xBM=; b=TF7/oAQV9jTQ7MXX3TZdDHBi7mnTWktj1fwycopWGGVROx6FUV0cgl0NJ7+FTsiVLl JQE+1dnurmF7V6Q9Z+vskKV8jLcYhR4j2MZ4juBkS0P5juqAZu23xxVtiMBWcz4MPn1V 1WddH5QBtbNs1ingSqyvCEg/wylCfqCfZSL1+bgMSK+bCxHWc47xZPIpmNFbPnuMsPzm Cz0DT9nVgOD5HXN171iLDTLpOUAH1OXtrdLWwIbWLwVsM/TIrtsV+dehwDAGJc9Z4Gwf XAg01sSJm640EYEUb9gUc0Tq3tl+yfCDOlMiezidfS5neB7go8qOM8I+DXzqAts6p/dp PBzA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=CW8jTqaD; spf=pass (google.com: domain of shinobius_monk@protonmail.com designates 109.224.244.27 as permitted sender) smtp.mailfrom=shinobius_monk@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1784047479; x=1784652279; 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:content-type :mime-version:feedback-id:message-id:subject:from:to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=pKrPusGCEvTKym+1X9a7yRW4p9Nc5q1ix7fxfi73Bi4=; b=mt29gnSz6IsgOa43gzXCnXqkLqEFngf8A6F99NdjZkmt8i4Fvfgm1kTopqw1P4Gmn6 VO4DbdolAPR9MCvohHMN35KioMu+GyeugvNdDQnK3Q+QFP+Ta585v3AW00qG7ZOVjQbu UwuGPFrjZic+mJwIh8xG02M1Y31UxXBntfa4nFGyAhDWArKSXvQiqZae4DgXmq5L0AkU 4eJuzn/jcIqOkR6cQ/Pt3aA/dw4fIs6AQvreVndL43BsppOS0dUaU4/0YPqb30JooDqV +UMhhpNwsYAaVg9mAf/KwDn0siQoNxMR9o7SGSAyD8/8gazrANwCTrKDQ7hMrBSHk/M2 l0+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784047479; x=1784652279; 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:content-type :mime-version:feedback-id:message-id:subject:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=pKrPusGCEvTKym+1X9a7yRW4p9Nc5q1ix7fxfi73Bi4=; b=MVvEefMLxFCl9iktNSMefp5rl7YPcgUOi8RyduAIFF9h0dbQkdznQGh8GqdKqPwTrd J/tHCRG3BtMtpasHY2sAS6BjC+maQGlDdz+hoEyaSdnRtXGWKyQlE9fQnHVe3a/0deb7 4vmQ8//fZDQtVRcEftaJLu+ujRub7izem6dY+YiFFdLX7KmbOrFhg7HPkTcFkAt9MaX3 Ya4a4vQJC1CfqxNx3LdvS8hisk0UUuVhZRLfFXbznAeay6Qg7sSfhMJ/1LVpUcXqlO3X 9IeXfewkmCIDPRCnc1YTyLydrHlNdDkLev/+FxgQHizqNDM2MMkjpSIDk86LRMjZekGG 032g== X-Forwarded-Encrypted: i=2; AFNElJ/Y6vQUnoqXdGKza3wgZT69kyI+YMF/4NQWtCVGnxgJ/EWkLyP6QZdsgzTDv6mWheVrUfiIZubKC5A4@gnusha.org X-Gm-Message-State: AOJu0YwpgFJkS7MklCZfYDpsU57ajC8wpmuu/Ho81BfPc+T1P2WyRnsR AxFbGbQE2ph3bJNwS4XYSvzj15ZkgLAsD4+QM9BK7SVcDOH7vM6k6T79 X-Received: by 2002:a05:6820:2081:b0:6a3:955b:846e with SMTP id 006d021491bc7-6a39a6e469dmr8736160eaf.34.1784047478728; Tue, 14 Jul 2026 09:44:38 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Aa7YSPQ8Rrw4QwvxlbyumxGtNmgpXDKomqxyOhWAYpeEpmz7xg==" Received: by 2002:a05:6870:c214:b0:447:88d1:85e7 with SMTP id 586e51a60fabf-451a59f764bls3034406fac.2.-pod-prod-05-us; Tue, 14 Jul 2026 09:44:33 -0700 (PDT) X-Received: by 2002:a05:6808:1810:b0:490:5ba4:18a3 with SMTP id 5614622812f47-4a42af07c4bmr10215018b6e.30.1784047473658; Tue, 14 Jul 2026 09:44:33 -0700 (PDT) Received: by 2002:a05:620a:a207:b0:92e:5517:4756 with SMTP id af79cd13be357-92efd04aaa2ms85a; Tue, 14 Jul 2026 09:39:22 -0700 (PDT) X-Received: by 2002:a05:622a:1f8e:b0:51c:7b12:6000 with SMTP id d75a77b69052e-51cbf2eafe8mr141064441cf.76.1784047161694; Tue, 14 Jul 2026 09:39:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784047161; cv=none; d=google.com; s=arc-20260327; b=MXJG6RlCgY5+GHMCusmrZY1+iXqKtjNNG9U6QOCMpNNMM8B6qJQrosUiFGYV2u3MbS +OZkaaO5Wy4PzPCPlanQxFOF0xHVN7gs5Sa3q1gIkSC3192eqsUukyz7fVMtphaTPLb6 5aNHPIqYjXRQTBRfZMsigHMKSHjEP+3CybsqhYY4iItv0w7fugSWYqIOh+OE8w+ldXr2 NkrhSo01TrvXNeJPQuVgBH+/LzDzi6JPxueLmChk5/zgn6lo7NsuIdqGpXW2EDzRjzNX Aar1nEc5UO8ink+1Od2m97KXDKLTtkhd8u0vMwaJxe1DFUF7eUnRrI+KArJZkvVdanP4 cyAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:message-id:subject:from:to:date :dkim-signature; bh=FcIaI5YzRDl8Ek4DUUs4UWgI8+bpAun7y7Gy24BEYsE=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=cTCvyA9N6U3oraE8KXUMgubVv2FK+zNnIrBMOoQc4KK8hJXk5e64Y/iHkEKq1OWdkB drrslcXm2YV/+myVZFZYnWI/wgqe7fo6IORpdXJjwxmyJT8NEzsfGMf0CkmskWZimvs2 pUVO2fsBCWAi/WmShDG6TOFi3RFQaoAWTAu9OHlKeHiEeLLBDDG0ZzlU39i+ebQQOljP GyQWQooZ406q62Rj9YwD7sUpwn52LnPIkZrqEKrKwjXkGo47Pd9c64ASqSq99pwpjqKa v+yYz9ecRlEVsM2E6A5zI77xzupSNLdCAquxvPyai15ZPO4lPeh0JMRGp4PHMe/CV0Ru 7X0w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=CW8jTqaD; spf=pass (google.com: domain of shinobius_monk@protonmail.com designates 109.224.244.27 as permitted sender) smtp.mailfrom=shinobius_monk@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-24427.protonmail.ch (mail-24427.protonmail.ch. [109.224.244.27]) by gmr-mx.google.com with ESMTPS id d75a77b69052e-51caafc633dsi4278901cf.6.2026.07.14.09.39.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 09:39:21 -0700 (PDT) Received-SPF: pass (google.com: domain of shinobius_monk@protonmail.com designates 109.224.244.27 as permitted sender) client-ip=109.224.244.27; Date: Tue, 14 Jul 2026 16:39:14 +0000 To: "bitcoindev@googlegroups.com" From: "'shinobimonkey' via Bitcoin Development Mailing List" Subject: [bitcoindev] Quantum Recovery Of Hashed Address Secured Coins With No Confiscatory Risk Message-ID: Feedback-ID: 119200758:user:proton X-Pm-Message-ID: ad4350f508e2104a042354ad74de37f2f54c266f MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_eKikII4VSs3DMfsStK3xPQPcjvKVchTRDK2DTscel0" X-Original-Sender: shinobius_monk@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=CW8jTqaD; spf=pass (google.com: domain of shinobius_monk@protonmail.com designates 109.224.244.27 as permitted sender) smtp.mailfrom=shinobius_monk@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: shinobimonkey Reply-To: shinobimonkey 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.0 (-) --b1=_eKikII4VSs3DMfsStK3xPQPcjvKVchTRDK2DTscel0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Currently the discussion around how to address the potential risk of a viab= le quantum computer centers around two primary issues: the quantum-safe sig= nature schemes (or schemes) to integrate for users to migrate to and use if= need be, and what (if anything) to do about any coins that remain secured = by vulnerable ECC based scripts, specifically should these coins be frozen,= and what mechanisms are available to allow legitimate owners to recover th= ose coins if possible without an attacker having the ability to do so. This second issue is (and always has been) a very socially contentious one,= as the common understanding is it is impossible to guarantee with certaint= y that no user is being left in a position where they are incapable of gene= rating a recovery proof, and therefore are forever prevented from accessing= their coins. My motivation for writing this is to solve this contention (at least partia= lly) in a manner that can hopefully move discussions forward in a productiv= e direction rather than lead to two opposing plans of action eventually col= liding in the real world with live implementations of conflicting rules. The current solution landscape as it stands to my understanding is: - BIP 32 hierarchical proofs, as proposed a decade or so ago by Adam Back a= nd recently implemented as a proof-of-concept by roasbeef. - Non-deterministic stateful proofs constructed and timestamped before a de= adline, showing a vulnerable ECC key signing off on a quantum-safe authenti= cation mechanism to be used for spending after a post-quantum spending rest= riction is activated - Tim Ruffing/Tadge Dryja's idea (I apologize, but I forget who was the act= ual originator of the proposal) of a commit-reveal migration scheme where a= transaction spending vulnerable ECC inputs must have an encrypted commitme= nt to that exact transaction confirmed in a block with a pre-determined num= ber of confirmations prior to the decrypted plaintext transaction's confirm= ation, or the decrypted transaction is invalid. All three of these proposals leave some subset of coins uncovered. HD proof= s are useless for users who generated their keys any other way than BIP 32,= stateful timestamped proofs are useless for any inactive user or someone w= ho for any reason does not create them before the creation deadline, and th= e commit-reveal migration is useless for anyone with an address type that i= sn't hashed because any attacker would have access to the material needed t= o create a valid pre-commitment for a spend. However, by layering them, and allowing any single one of them to be used, = complete coverage of any conceivable key generation method can be achieved = for hashed address types. Coverage of non-hashed address types is fundament= ally impossible, because the requirement to allow use of commit-reveal migr= ation would inherently leave such address types still exposed to a quantum = attacker. - Hierarchical proofs cover any BIP 32 user - Stateful timestamped proofs cover any active/observant non-BIP 32 user - Commit-reveal covers any non-BIP 32 user who is inactive/not observant The only case in which I can see a restriction of hashed address type spend= s using this layered approach of recovery would leave a user unable to reco= ver their coins is if they have lost access to their private keys. That cas= e is completely outside of the scope of any of these proposals, and inheren= tly impossible to cover. Shinobi Sent with [Proton Mail](https://proton.me/mail/home) secure email. --=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/= sdGGYMMWowlFff6Yh8usMel61HVYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNLef4eDwNgfR= eiK-7j-sYn1jlXHPoAPWAwNBbSJxEz3M%3D%40protonmail.com. --b1=_eKikII4VSs3DMfsStK3xPQPcjvKVchTRDK2DTscel0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently t= he discussion around how to address the potential risk of a viable quantum = computer centers around two primary issues: the quantum-safe signature sche= mes (or schemes) to integrate for users to migrate to and use if need be, a= nd what (if anything) to do about any coins that remain secured by vulnerab= le ECC based scripts, specifically should these coins be frozen, and what m= echanisms are available to allow legitimate owners to recover those coins i= f possible without an attacker having the ability to do so. 

This second issu= e is (and always has been) a very socially contentious one, as the common u= nderstanding is it is impossible to guarantee with certainty that no user i= s being left in a position where they are incapable of generating a recover= y proof, and therefore are forever prevented from accessing their coins.&nb= sp;
My = motivation for writing this is to solve this contention (at least partially= ) in a manner that can hopefully move discussions forward in a productive d= irection rather than lead to two opposing plans of action eventually collid= ing in the real world with live implementations of conflicting rules. =

<= /div>
The cu= rrent solution landscape as it stands to my understanding is: 

  • BIP 32 hierarchical proofs, as proposed a decade or so ag= o by Adam Back and recently implemented as a proof-of-concept by roasbeef.&= nbsp;
  • Non-determinist= ic stateful proofs constructed and timestamped before a deadline, showing a= vulnerable ECC key signing off on a quantum-safe authentication mechanism = to be used for spending after a post-quantum spending restriction is activa= ted
  • Tim Ruffing/Tadge Dryja= 's idea (I apologize, but I forget who was the actual originator of the pro= posal) of a commit-reveal migration scheme where a transaction spending vul= nerable ECC inputs must have an encrypted commitment to that ex= act transaction confirmed in a block with a pre-determined number of confir= mations prior to the decrypted plaintext transaction's confirmation, or the= decrypted transaction is invalid. 

All three of these proposals le= ave some subset of coins uncovered. HD proofs are useless for users who gen= erated their keys any other way than BIP 32, stateful timestamped proofs ar= e useless for any inactive user or someone who for any reason does not crea= te them before the creation deadline, and the commit-reveal migration is us= eless for anyone with an address type that isn't hashed because any attacke= r would have access to the material needed to create a valid pre-commitment= for a spend. 

However, by layering them, and allowing any single one of t= hem to be used, complete coverage of any conceivable key generatio= n method can be achieved for hashed address types. Coverage of non-hashed a= ddress types is fundamentally impossible, because the requirement to allow = use of commit-reveal migration would inherently leave such address types st= ill exposed to a quantum attacker. 

  • Hierarchi= cal proofs cover any BIP 32 user
  • Stateful timestamped proofs cover any active/observant non-BIP = 32 user
  • Commit-reveal= covers any non-BIP 32 user who is inactive/not observant 
    • =
=
T= he only case in which I can see a restriction of hashed address type spends= using this layered approach of recovery would leave a user unable to recov= er their coins is if they have lost access to their private keys. That case= is completely outside of the scope of any of these proposals, and inherent= ly impossible to cover. 

Shinobi

Sent with Proton Mail secure email.

--
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/= sdGGYMMWowlFff6Yh8usMel61HVYmV8KPMqT9np2kK7GxPbVaogJ2aJSFe4v16VNLef4eDwNgfR= eiK-7j-sYn1jlXHPoAPWAwNBbSJxEz3M%3D%40protonmail.com.
--b1=_eKikII4VSs3DMfsStK3xPQPcjvKVchTRDK2DTscel0--