path: root/dc/b2b6b5a1ac6c4a02aa6665ef6e3022400f2407

Delivery-date: Mon, 02 Jun 2025 13:03:05 -0700
Received: from mail-oo1-f55.google.com ([209.85.161.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCL7RHHJZYJBB3UG7DAQMGQEDPAX3EQ@googlegroups.com>)
	id 1uMBNA-0005Bq-0y
	for bitcoindev@gnusha.org; Mon, 02 Jun 2025 13:03:05 -0700
Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-60ed8bbe694sf1529143eaf.0
        for <bitcoindev@gnusha.org>; Mon, 02 Jun 2025 13:03:04 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1748894578; cv=pass;
        d=google.com; s=arc-20240605;
        b=OQXwlNDK5RqSfdvT+haOPFbyOS/VRZWKY5/Ilix9WnzGOJi8Nj3qmd/+9I2Om7Sr4M
         3C4qKHhMEAsvnT9wgwywa+wp2ocg7S6rqtdJixJJjCuw7SpPr93W0J7L+wgG3gO07DS3
         arvfbhy7snN5zsgpsWkvAPBODCsYfKOWs8XaJjzOLR3+zNTtxsoPWltglKvzHQ6x98LN
         0b4j0X/TkBxPf1sVchkjB7sC8QJmUHOjz8n2GxhgWXKofxiVLPsUYHnjpymj3auwGttC
         syBxcVSF3RShj5AzeN3WmEVTLjNauuil8jNv/D99k7fV7sEolyMlXsRKSIPiy6EZmkXp
         modw==
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=n0SGDC0v3IO29M9AbEuZuaB9x4bXO8WcHIhjzFWZOQc=;
        fh=CehsiRASeGVXg3PIPpZRhm+/uQNAhM+/D3fFHFhsV+s=;
        b=EPEJMO1TDeesnjby6ybGRZhFCCQQ8zLs9bhSnL8VooIXoB9GEAtfrzsamAYI+CAQI6
         LFRtwZLUERZPqdXNJzKlNPj4NlgldzVRAtrdid2kQ4AFHenPDs/64xUWE+Bdo7LApqB6
         S0Ny1LQSI926qR5a1JX+JsrMbCrT+3Sx6iLmrASlqJJibpPQF1AlTKNuNkTdlKTfFPc2
         OrFXE/91nW/QTLdyt+JxciIxmT4OS7o/YE12SH7/9gaLD2i7Y9TW1LJ1s/MdMlSfFr7S
         50TteedP/kcNXHIKkWsI1fPMEnLMp+n8KzzowYBa0z5a1XZLx9hxTWxnKIaVXYPtuL8m
         RkrQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=c8Uuhp+u;
       spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.31 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=1748894578; x=1749499378; 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=n0SGDC0v3IO29M9AbEuZuaB9x4bXO8WcHIhjzFWZOQc=;
        b=ZF+87MRL9z/nvIlYdGtD8dvZ1NGJu2amm/e+VenApzJyIgKrJTmfTRNQkxWPBtLUG0
         jowyEaSESlrOLKk1yxfAhWD8TeLI/IEHAJcnt6sFCFskc9wZFT9N7eS+C80EYeMZCG/n
         UodJqRi1Xrrhkgmwjw8H2aXFHoPAsTxrTAKA+hiZhLl66+UvtD1CN7QXqN2x73IVuGdp
         F+pwVtkRndUgpVCdbuDoQ1+TpLG701HtWXi4hbWJ0/eHiiKE//Qh/aInEovo4DmNj+xp
         sjo1cgdkrKSOj0/EToP1oPJ2HK+c+esiixDjh1k/7Ki97k+3W6kMo9HvhVkQfsEYy3+J
         7X9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748894578; x=1749499378;
        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=n0SGDC0v3IO29M9AbEuZuaB9x4bXO8WcHIhjzFWZOQc=;
        b=WY5B4KY8A0vyu3LGmvhmxg3arkHJlw43jjpmV4GrT4SjZ+/dGDI5TMaVFCqqjS03jj
         bVfde4ZmphXJmIuBnIuBzbNQTqULExQ2LWAcZZKnG1rTWQcFaTJdnQd+qv0wIt+NBUBV
         mmULszizY13FxOiz92wuhjh03QujdjU8InNTIW9epVrZvH6/6We61uruviavasDMpKJm
         YbRAGa91I0ozceXt1Im4jCHwGc++f64prAJD9jhV0vFLvrhTVUrCLmtJAtSyA/Tjh8u/
         oV4p/zeQ5TmtgHauLSKre8GyYcoMhaTP7pYZhgQepULaTMWnEWKKY1UZwKbLp3t/jMRt
         hb2w==
X-Forwarded-Encrypted: i=2; AJvYcCV0GW37fzeEPmvCEqZOnAC/P0aMZY5a4ighfjtK5yoDaI2esxHaYvoRerSC0GRTVJQHdR3Vx5GBY0pS@gnusha.org
X-Gm-Message-State: AOJu0YxV7dVei6QFuONVwQ+86P2uEty12isRtP+5PwkIiSAVFk7Couou
	SDhL9gL0Nk3xEKVmxKVQbb3vMmqBvDjWjhWTsNFMvAM5vR7MtE332b9d
X-Google-Smtp-Source: AGHT+IHgWjHx8rh+4ibpqj2eR07ec7O9l3QIII9hgyqPxuF7DlFnUjMo5mt6BEhklQk8I+f1D15bvA==
X-Received: by 2002:a05:6820:310a:b0:60a:26f:ad8d with SMTP id 006d021491bc7-60efbc192a4mr605039eaf.0.1748894578045;
        Mon, 02 Jun 2025 13:02:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfvlrALdkukMsP0rJ2snqS5CgMhwOCsmSnMwHgwzeVN4A==
Received: by 2002:a4a:b641:0:b0:60b:c628:4ae0 with SMTP id 006d021491bc7-60be52b81b0ls1159094eaf.0.-pod-prod-00-us;
 Mon, 02 Jun 2025 13:02:54 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCW7hOMG7SA4UlNKKamRwQRJ5YDz9Dl65nx9cC4HAq+OW2A6BwfSRJTBkoBZ1y3RfpD7+KK3l/Q0BGXd@googlegroups.com
X-Received: by 2002:a05:6808:4409:b0:3f3:d6f9:69a5 with SMTP id 5614622812f47-408e1603ba2mr531478b6e.8.1748894574323;
        Mon, 02 Jun 2025 13:02:54 -0700 (PDT)
Received: by 2002:a05:6504:1294:b0:2b1:9db7:3101 with SMTP id a1c4a302cd1d6-2b1a1c1d5f4msc7a;
        Mon, 2 Jun 2025 11:29:40 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUN4wP6dSDY3UclF955fip01fEMfKYslr3VMJ2GFsxt1cc6bzzHKaKc1YxaefrLB7LtfCPQ+Mj8XJp8@googlegroups.com
X-Received: by 2002:a05:6512:ea0:b0:54f:c2ca:d33 with SMTP id 2adb3069b0e04-5533b8f40f1mr4265692e87.20.1748888978489;
        Mon, 02 Jun 2025 11:29:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1748888978; cv=none;
        d=google.com; s=arc-20240605;
        b=OWQ/uYeVkR79aDeVwUWljUUG5zHPWE0Ll3jXB2WDphZLs/wpzNxxijgOsF3Wigy0Ch
         rF0p8LxRnuFUnbcoiH484PZYV2TceMEpMvnsFyd6HMgEsO1v8e/lgYqr3oZjryiCBKK1
         Vwei0wsCC3P865s/td4L4U1pgVFmbrFAuX7zGAuDonMmWRXSdVofOF3EuS5tVArBdXh0
         B0z3JtjCNOR7/ifoCoWJKtmnRO/0l7gZpsDA6hraE999lgcUQ9JxaLznL/ngWw59QJQJ
         4qwV7uIJeQjG09qqDzG8B7S/924mGE7pWRut9Cwm3FXX95kqSOl035mpju4wZhcKHUC6
         9JkA==
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=mns9tZEwsUfzG2h16EuUza8lEu4vRzfYOD4Ncx0G04U=;
        fh=cUAOE1g5NF+ykVuv68pI9lr57ssbirWSMUSZVQQ4NEw=;
        b=CKcfI2Y4yleWHJvSMHL3zTg70pLEAsYpfe6gq4Nd1QD8y6l8YGOtA0jRN/tJipFojN
         QzAvRmiyv2xK3SNI0EPcuuC6t/WFc9QOQHnzQrrLB2n4c+FGt/mKBBMrk3YC7KIigZpW
         T3m0Vt25vFK5QBGrkJccMYEEsi17DO1Cs5odbEkoAwHj7HJOj+sEoynr11t1W6I7FFlt
         APVxOeU49LiE8e5Foj4PHTPHieJU7Kukctn2MHYDrOY+ND33zap+M8A1i8iF7C01Wscd
         2PXE/brmTU5cH1+sGxyksWo/4Qnithlz2H9fFX/XGz9290jeN1e4JeRIEK85+hvWVo+x
         6PKw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@proton.me header.s=protonmail header.b=c8Uuhp+u;
       spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.31 as permitted sender) smtp.mailfrom=conduition@proton.me;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
Received: from mail-10631.protonmail.ch (mail-10631.protonmail.ch. [79.135.106.31])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-553377d2bcasi87027e87.0.2025.06.02.11.29.38
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 02 Jun 2025 11:29:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.31 as permitted sender) client-ip=79.135.106.31;
Date: Mon, 02 Jun 2025 18:29:31 +0000
To: Nagaev Boris <bnagaev@gmail.com>
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Lloyd Fournier <lloyd.fourn@gmail.com>, Antoine Poinsot <darosior@protonmail.com>, =?utf-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>, Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure
Message-ID: <U-sRQaR4nYAASzloafdreD8rQrNPk69IfuEL-PBsQ74uXheZUlYk89uFw80Kaa-cGJJy-_q-PBTY05PbU05n52mV2VheBEyntlTF7sfc_og=@proton.me>
In-Reply-To: <CAFC_Vt4wjLV_iAHYDMcAJYP=PRo=jNWQzmrUfJUK2_GXTiPnjA@mail.gmail.com>
References: <CALkkCJY=dv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ@mail.gmail.com> <XHIL8Z4i4hji8LhbJ0AiKQ4eago2evXwjTGUOqqyAye_2nM3QicDpHo6KkcznBAHPUrIWSLj_GuiTQ_97KPjxcOrG8pE0rgcXucK2-4txKE=@protonmail.com> <CAH5Bsr0muoF27besnoQh32vL-keujeR+d-_JurE0+yXY5gPKQg@mail.gmail.com> <Rgj4DeSKQkdEWMRTmqYYLas84WIDyRftEKqmwlw0C9-ur4Tx9_d6g7SzTU_WBspYbezLDTMpgIFXon1_cpFSjgYOMtHlQJNS_utF2dZQ4ig=@proton.me> <CAFC_Vt4wjLV_iAHYDMcAJYP=PRo=jNWQzmrUfJUK2_GXTiPnjA@mail.gmail.com>
Feedback-ID: 72003692:user:proton
X-Pm-Message-ID: 990107929f813a70cb0eded21522f2f7985e1962
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------0e8bf7b683726924cb0297fb829a524ec76f0c2392de75edb7fcc8263135b91d"; 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=c8Uuhp+u;       spf=pass
 (google.com: domain of conduition@proton.me designates 79.135.106.31 as
 permitted sender) smtp.mailfrom=conduition@proton.me;       dmarc=pass
 (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me
X-Original-From: conduition <conduition@proton.me>
Reply-To: conduition <conduition@proton.me>
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: -1.0 (-)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------0e8bf7b683726924cb0297fb829a524ec76f0c2392de75edb7fcc8263135b91d
Content-Type: multipart/mixed;boundary=---------------------7c978a9d780e41d375363e4b29b1678f

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

Hi Boris,=20


> Isn't this a bit of a chicken-and-egg issue? The EC signature signs
> the second transaction, which depends on the QR output's txid, which
> in turn depends on the precommitted EC signature.

Sorry, my wording was vague in my last message. I was picturing an
arbitrary EC signature, possibly on a static message,
e.g. sign("i was here first!", sk). Not an EC signature on the
reveal transaction, because you're right - that would be a cyclical
dependency.

I was thinking we commit to sha256(sign(static_msg, sk)) using a
quantum-protected address in the commitment stage. In the reveal
transaction, we open the commitment by revealing=20

sign(static_msg, sk), spending both the QR and EC UTXOs.

However, I like your idea of committing to the pubkey instead of a
signature - it's simpler. As you said, we can't give the QC attacker
opportunities to steal and so the commitment must be hidden until it
is revealed when it comes time to spend the EC output. This applies
to any kind of commit/reveal scheme, whether we use signatures or
pubkeys.

The exact mechanics will depend on what commitment mechanisms are
available to users of the hypothetical quantum-resistant script pubkey.
Best case is we hope to have a taproot-like tweaking mechanism that
lets us hide a commitment in the QR output script, or we use a P2SH
wrapping layer around a hypothetical quantum-resistant checksig
opcode, and hide the committed data in an inscription-like envelope
which is opened by the reveal transaction.


For better scaling, we probably want to commit some kind of
accumulator, rather than just a single raw hash. Otherwise you'd
need one QR UTXO to spend every locked EC UTXO, which isn't very
efficient. For instance, say you have 10 locked EC utxos you want
to rescue using a single QR output. You create a new QR output
which hides a commitment to sha256(pk0, pk1, ...pk9) (or a merkle
tree root of same). This way, a single QR output can be used
to prove prior pubkey knowledge for an arbitrary number of
legacy addresses.


-conduition






On Monday, May 26th, 2025 at 11:42 AM, Nagaev Boris <bnagaev@gmail.com> wro=
te:

> Hey Conduition,
>=20

> Isn't this a bit of a chicken-and-egg issue? The EC signature signs
> the second transaction, which depends on the QR output's txid, which
> in turn depends on the precommitted EC signature. One way to break
> this circular dependency is to use the SIGHASH ANYONECANPAY modifier
> to exclude the QR output from the EC signature scope. Or an
> inscription can be used to commit to the EC signature without
> affecting the txid of the first transaction.
>=20

> That said, I've been thinking about an alternative approach that might
> also be more convenient in practice.
>=20

> What if we commit to the SHA256 of the EC public key instead of the EC
> signature? If this hash is included in a QR output at least X blocks
> in advance, it offers the same security under the assumption that a
> quantum attacker can recover the private key from the public key.
>=20

> However, there's a problem: an attacker can observe the creation of QR
> outputs and create their own outputs committing to the same
> SHA256(pubkey) in advance. To prevent this, the commitment to the EC
> pubkey hash must be hidden from observers. One way to achieve this is
> by embedding SHA256(pubkey) in a Taproot leaf. Since Taproot leaves
> are not visible on-chain until revealed, the attacker can't learn
> which pubkeys are being committed to. Once the commitment is revealed
> at spend time, it's too late for the attacker to make a QR output and
> wait out the delay. Multiple EC inputs of a transaction can reuse the
> same QR input of the transaction.
>=20

> The pubkey (and its SHA256 hash) is only revealed when spending an EC
> output. A new consensus rule would require that such a spend be
> accompanied by a QR output, with a tapleaf committing to the SHA256 of
> the same EC pubkey, created at least X blocks earlier and spent in the
> same transaction. An attacker seeing the EC pubkey in the mempool
> would have to create their own QR output committing to the same hash,
> mine it, wait X blocks, and then attempt an RBF =E2=80=94 but by then, th=
e
> legitimate transaction would likely be confirmed.
>=20

> From a usability standpoint, this seems cleaner: the user can
> precommit to the SHA256 of the EC pubkey in advance and decide how to
> spend it later. For example, if you're managing multiple EC UTXOs
> (say, 10), you can commit to all of them in a single transaction
> creating QR outputs, and handle second-stage spends later as needed.
> This is not only simpler but also more efficient. You can also create
> a single QR output with many tapleaves committing to SHA256 hashes of
> multiple EC pubkeys, and spend all the EC coins plus one QR coin in a
> single transaction.
>=20

> In the original scheme, if the user has multiple EC UTXOs on the same
> legacy EC address, they would need to create a separate QR output for
> each one and spend all EC+QR pairs together in a single transaction.
> With this alternative, a single QR output committing to the pubkey
> hash can authorize the spend of multiple EC UTXOs in one transaction.
> That significantly reduces the number of QR outputs required when
> consolidating funds from a single EC key. Note that such coins must be
> spent all together in both schemes, because spending a subset reveals
> the EC pubkey, making the remaining coins vulnerable.
>=20

> Would be curious to hear if others have considered this route or see
> potential pitfalls.
>=20

> Best,
> Boris
>=20

>=20

> On Sun, May 25, 2025 at 3:38=E2=80=AFPM 'conduition' via Bitcoin Developm=
ent
> Mailing List bitcoindev@googlegroups.com wrote:
>=20

> > Hey friends,
> >=20

> > Even if we can require a pre-quantum output to be paired with
> > a QR output when spending in this way, and even if the QR output
> > must be at least X blocks old... What prevents an attacker from
> > just pre-minting a whole bunch of QR outputs, aging them for a while,
> > and then lying in wait to steal?
> >=20

> > A well-prepared QC attacker's QR outputs may even be significantly
> > older than an honest user's QR outputs. An aged QR output committing
> > to a QR signature proves nothing about the ownership of an unrelated
> > pre-quantum UTXO.
> >=20

> > The QR output must prove historical ownership of the vulnerable
> > EC key-hashed output. To fix this, we must change this line in OP:
> >=20

> > > 2. the user creates a transaction that, aside from having a usual
> > > spendable output also commits to a signature of QR public key.
> >=20

> > This transaction must be fully protected by QR signing. It must
> > commit to, but not reveal, the EC public key, while also proving
> > ownership. I would correct this description to:
> >=20

> > > 2. the user creates a transaction with at least one QR input which,
> > > aside from having a usual spendable output also commits to
> > > a signature from the legacy EC pubkey.
> >=20

> > This TX might have an OP_RETURN output or an inscription which embeds
> >=20

> > SHA256(ec_signature). Or, like taproot, the QR output script might
> > itself contain a hidden commitment to that hash.
> >=20

> > A few blocks after this transaction is mined, the honest user can
> > spend the QR and legacy UTXOs together, opening the EC signature
> > commitment. Validating nodes would have to check the QR output is
> > old enough, but also check that it committed to the correct
> > pubkey+signature.
> >=20

> > A QC attacker shouldn't be able to break this unless the legacy EC
> > pubkey has already been revealed prior to the commitment TX.
> > Only the authentic user could've pre-committed to that signature.
> > If we assume the QC attacker can't roll-back the chain more than
> > X blocks, they can't go back and insert an EC sig commitment
> > retroactively.
> >=20

> > I suspect this might've been Martin's intent, judging from the way he
> > was writing?
> >=20

> > regards,
> > conduition
> >=20

> > On Sunday, March 23rd, 2025 at 8:24 PM, Lloyd Fournier lloyd.fourn@gmai=
l.com wrote:
> >=20

> > > On Tue, 18 Mar 2025 at 00:48, 'Antoine Poinsot' via Bitcoin Developme=
nt Mailing List bitcoindev@googlegroups.com wrote:
> >=20

> > > > I suppose you could in theory have, in addition to making spending =
old outputs invalid on their own, a rule which dictates they may only be sp=
ent along with a QR output at least X blocks old. This would give the hones=
t user a headstart in this race, but meh.
> >=20

> > > Yes this is how I read the OP "after sufficient number of blocks". I =
think this is a really nice idea. The head start can be arbitrarily large s=
o that the attacker simply cannot compete. It's probably not too difficult =
to design some honest RBF mechanism either such that you can bump the fee w=
ith a new QR signature if it's taking too long.
> >=20

> > > LL
> >=20

> > > > On Sunday, March 16th, 2025 at 2:25 PM, Martin Habov=C5=A1tiak mart=
in.habovstiak@gmail.com wrote:
> >=20

> > > > > Hello list,
> > > > > this is somewhat related to Jameson's recent post but different e=
nough to warrant a separate topic.
> >=20

> > > > > As you have probably heard many times and even think yourself, "h=
ashed keys are not actually secure, because a quantum attacker can just sna=
tch them from mempool". However this is not strictly true.
> >=20

> > > > > It is possible to implement fully secure recovery if we forbid sp=
ending of hashed keys unless done through the following scheme:
> > > > > 0. we assume we have some QR signing deployed, it can be done eve=
n after QC becomes viable (though not without economic cost)
> > > > > 1. the user obtains a small amount of bitcoin sufficient to pay f=
or fees via external means, held on a QR script
> > > > > 2. the user creates a transaction that, aside from having a usual=
 spendable output also commits to a signature of QR public key. This proves=
 that the user knew the private key even though the public key wasn't revea=
led yet.
> > > > > 3. after sufficient number of blocks, the user spends both the ol=
d and QR output in a single transaction. Spending requires revealing the pr=
eviously-committed sigature. Spending the old output alone is invalid.
> >=20

> > > > > This way, the attacker would have to revert the chain to steal wh=
ich is assumed impossible.
> >=20

> > > > > The only weakness I see is that (x)pubs would effectively become =
private keys. However they already kinda are - one needs to protect xpubs f=
or privacy and to avoid the risk of getting marked as "dirty" by some agenc=
ies, which can theoretically render them unspendable. And non-x-pubs genera=
lly do not leak alone (no reason to reveal them without spending).
> >=20

> > > > > I think that the mere possibility of this scheme has two importan=
t implications:
> > > > > * the need to have "a QR scheme" ready now in case of a QC coming=
 tomorrow is much smaller than previously thought. Yes, doing it too late h=
as the effect of temporarily freezing coins which is costly and we don't wa=
nt that but it's not nearly as bad as theft
> > > > > * freezing of these coins would be both immoral and extremely dan=
gerous for reputation of Bitcoin (no comments on freezing coins with reveal=
ed pubkeys, I haven't made my mind yet)
> >=20

> > > > > If the time comes I'd be happy to run a soft fork that implements=
 this sanely.
> >=20

> > > > > Cheers
> >=20

> > > > > Martin
> >=20

> > > > > --
> > > > > You received this message because you are subscribed to the Googl=
e 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/b=
itcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmai=
l.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, s=
end an email to bitcoindev+unsubscribe@googlegroups.com.
> > > > To view this discussion visit https://groups.google.com/d/msgid/bit=
coindev/XHIL8Z4i4hji8LhbJ0AiKQ4eago2evXwjTGUOqqyAye_2nM3QicDpHo6KkcznBAHPUr=
IWSLj_GuiTQ_97KPjxcOrG8pE0rgcXucK2-4txKE%3D%40protonmail.com.
> >=20

> > > --
> > > You received this message because you are subscribed to the Google Gr=
oups "Bitcoin Development Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to bitcoindev+unsubscribe@googlegroups.com.
> > > To view this discussion visit https://groups.google.com/d/msgid/bitco=
indev/CAH5Bsr0muoF27besnoQh32vL-keujeR%2Bd-_JurE0%2ByXY5gPKQg%40mail.gmail.=
com.
> >=20

> > --
> > You received this message because you are subscribed to the Google Grou=
ps "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/bitcoin=
dev/Rgj4DeSKQkdEWMRTmqYYLas84WIDyRftEKqmwlw0C9-ur4Tx9_d6g7SzTU_WBspYbezLDTM=
pgIFXon1_cpFSjgYOMtHlQJNS_utF2dZQ4ig%3D%40proton.me.
>=20

>=20

>=20

>=20

> --
> Best regards,
> Boris Nagaev
>=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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/CAFC_Vt4wjLV_iAHYDMcAJYP%3DPRo%3DjNWQzmrUfJUK2_GXTiPnjA%40mail.gmail.com.

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
U-sRQaR4nYAASzloafdreD8rQrNPk69IfuEL-PBsQ74uXheZUlYk89uFw80Kaa-cGJJy-_q-PBT=
Y05PbU05n52mV2VheBEyntlTF7sfc_og%3D%40proton.me.

-----------------------7c978a9d780e41d375363e4b29b1678f
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==
-----------------------7c978a9d780e41d375363e4b29b1678f--

--------0e8bf7b683726924cb0297fb829a524ec76f0c2392de75edb7fcc8263135b91d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0Fgmg97XkJkHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdk0Qo+cJ3AfvXYKqq0FqHd1Ma19jfKytOET73T
5AX55hYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAf9wD9FKvtiLvilURBBtZj
QJIZrdCJP05ovMcKHw2ersS80UQA/jN6nT4cBjQf7ABFwnKPsR0XBI1oNW1g
arzP63wilMcN
=gDzB
-----END PGP SIGNATURE-----


--------0e8bf7b683726924cb0297fb829a524ec76f0c2392de75edb7fcc8263135b91d--