path: root/a9/1a9b19ab3bd1d949ce15be1b94db1c202e02d3

Delivery-date: Mon, 17 Mar 2025 06:37:03 -0700
Received: from mail-oi1-f192.google.com ([209.85.167.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDZPZFXW2IMRB5WK4C7AMGQEMWSGQMQ@googlegroups.com>)
	id 1tuAeM-0003ru-Gw
	for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:37:03 -0700
Received: by mail-oi1-f192.google.com with SMTP id 5614622812f47-3f9ce53ab0bsf4108938b6e.2
        for <bitcoindev@gnusha.org>; Mon, 17 Mar 2025 06:37:02 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1742218617; cv=pass;
        d=google.com; s=arc-20240605;
        b=F0GbHISQpJcYVOJRGzK6ny4pjXd5Mbifb+hshtG3kWBwqeSdRo8LgwIBNnSDUTMSUV
         NUEkZlRyvOz2OJ2a0Ssys5vsjUjWOnQ3EhUO0DMn10cgsFYj/Uos1JF6lTjndSPVKUCu
         qMm7Jyd/QIUlRp6wTQYF6n7UO0oM7T/kFlEHVGSmvEp6YkiGjgW/1tRi+XhtJWwhksVJ
         xUnPFOZ3xiuXRZfQTrKaTdR9KFsu2a0+ebx1om2HspUYxO80V/lQ+eN3WAwNAgLjxaNX
         mCDg4sBhLbnFC3uNr9+dmY6V93v3tlhgPlu6dxhAKlgC5niJr3I0TpdNfeGRKE3DJcX8
         24gQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=SOFZ+DPnOOb3hFrNs4RFBEZxbKDgqvN0F2WsD45kVqw=;
        fh=NBymDEtihQ7J/kwRXgNEc7PE2L6UGKX8iZoSECSSv6g=;
        b=aw4WjWidgJGZc2XXAU4PwRr3SBcb1xnjMtB/pWCCti7eO7mwFf7siuqzoO0nyHz18Y
         kF1Va/Ih/pmHp0Ep5fxYvoJxP1e78n3W3QziHqfU53AWV7/UJxQqC1ZkaajnLfR+2dof
         OOPqBMEiN2NOrUAdu11dCXH0rURVLXS7WcHflbiiFzl9dLcrSKSYGt6fHnSiWVwTxDlh
         9V1XAd/B7U1XLJUAmXCO9BJlwOu3KAT35Inxpmul1pwbi8ln3QfIDx4crkbjWIW5Dad+
         /noLWPAM5YVlDIQTvMk83uwdSz5gGkndzQH4Xzsriynkc4o07lqGq/rCz8/36NmjP7JQ
         BNjA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=RgGAtY1F;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1742218617; x=1742823417; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=SOFZ+DPnOOb3hFrNs4RFBEZxbKDgqvN0F2WsD45kVqw=;
        b=fK+1tlJ9w7OeW+w4Xg/+wyD3vAxvRClaJ/nbsgYEXv7dZ2Z3U1A3z/pWJVq/T6t9zz
         xqPKFtafweyit+sYA+GoypovCEQA8plPbD7WUfCUntiiwCb7E4XxF7gjEPcJvBy+0o9R
         4nWXQ2NRO/AsbBtj3Ebi+KzN0lOPah9FLWXWlhbwOQniZ2HKbaIrqFpaC6RjjrtX31AF
         jFHIlYweFA9VdwpeWtuXBh6AQzfaW8uds8XJn8IiATNY88Utnwzij4QShDqyMe7oFdqv
         2W4gwuVxDaSAFd90KQASbmlrpqj+ullcbxGl/73FcKbijI4Ue5ngX28LJWl0CHg2Zqxu
         Z2Ow==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1742218617; x=1742823417; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=SOFZ+DPnOOb3hFrNs4RFBEZxbKDgqvN0F2WsD45kVqw=;
        b=T591FhPIOu8Telbl0PWdZ7U/4zQeXLoE8YcbTND5e0lOJisC9rhJ7uCnRUIMURaAMA
         JLJWxp/A81vSsmGRkTC2kv+JWj8mnannQqmN7gbOY4n58ir/dr47Rjw1tkUR1P1LwZaS
         iJtNY4SDAUv0j9MWzuE25MU2a76/u+8d+MzYTedLOejsb1AdKI5trMOGPFQkU8XY/2oD
         yHr9u5sjID+IiCtpKmhPIda8I/Uo92G2gQ+vTVwJ2qhehKfeotJMkRIVSB+0/bwaKE2f
         7UfeorqYth5iRxIJ+BIMFcQkLljeIbDi/eoZlshwKIivUi9SdwEikxyCSN2E877WkwYC
         I2MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742218617; x=1742823417;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=SOFZ+DPnOOb3hFrNs4RFBEZxbKDgqvN0F2WsD45kVqw=;
        b=YJMChiv0gUOBWWM1mKuxiW/6/IfbiShdfyitlCXe+Uj1WvcoNbeK57Gb0dbrBC3sfd
         b5fbfqdw2Goz6BweS4ZAdABuPTPQv/lB2zXAwwb3nMndDaJpCE6Akoe1r7eOLU3el+rR
         fcczsh6EuaVIyBVyNxuIuNNv/GqLi2hUC1zDvswmvcGjhcfF9N42PhXRNYU/mvBFb0CB
         NagvNDoGhzF2obXyR84yGBuA2LFs1P32a7/Iu7jhGhVQJ9W+DohJn0FN368AtzIROWtH
         j/HOX8X2jDBKnmObu9opkLSH17u/bwzM22VD2FP4TOSpD5riw9ScVMoV+evWjZBpvmkx
         s04w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVQoNoclZ8XJK4xz5Nrk4iNpcdeKWSoOjNZEtIk0TYQ88+JVCKW6vvOW1AKABtYP8IK8/ecAY1NbhmF@gnusha.org
X-Gm-Message-State: AOJu0YyCTojNABFYCyaEag8IS8VbCn7kCdtnCfpD1Ri5+aK+fcqXZzbc
	A4uolsNMr1y/4rC5i/+alwXC2Uh+6BY9MZ6yP8b+ash6iCaGR6F1
X-Google-Smtp-Source: AGHT+IGiBY4YSvEqCYa8PLwj/GbSeM15X9MDXLPyEA8QqWGiFFyPzYkp4SAb2Sqhb0I921u7uoDJtw==
X-Received: by 2002:a05:6808:1a1e:b0:3fb:3be7:acac with SMTP id 5614622812f47-3fdeeb1f99cmr5287369b6e.21.1742218616801;
        Mon, 17 Mar 2025 06:36:56 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALOIuMQnXjEsW0CN1X9zPNNSCW4ilaEdW653Z821EH5qQ==
Received: by 2002:a4a:ea87:0:b0:5fe:95f4:b2dc with SMTP id 006d021491bc7-601d8898eccls1434009eaf.1.-pod-prod-03-us;
 Mon, 17 Mar 2025 06:36:54 -0700 (PDT)
X-Received: by 2002:a05:6808:1899:b0:3fc:219:c620 with SMTP id 5614622812f47-3fdeec1603fmr5884357b6e.23.1742218613987;
        Mon, 17 Mar 2025 06:36:53 -0700 (PDT)
Received: by 2002:a05:6808:8f0:b0:3f6:a384:eb6f with SMTP id 5614622812f47-3fddc3d65c1msb6e;
        Sun, 16 Mar 2025 13:52:59 -0700 (PDT)
X-Received: by 2002:a17:90a:d610:b0:2ea:712d:9a82 with SMTP id 98e67ed59e1d1-30151d817femr12462240a91.29.1742158378511;
        Sun, 16 Mar 2025 13:52:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1742158378; cv=none;
        d=google.com; s=arc-20240605;
        b=BZrgWvy4RDRRJkgcvPF4bNuhhCTeWWdNj50WDtFMTSzdXgHgQ7sBBi3NgZ7ayK9jgg
         gxSe0AlTcGsXflj8ft/Gg3cLX5AagxwQiVQfqMOcoeN+EORpyDl+3v/g7cqu/azfIt8t
         BPQD1vFsnx/WI3tXQQQe9Sv0dRDTrJk9WQwpF0U+rTkoCdJgQt69fjf5KXOkhLNVtWsk
         br7zbkgM+RqIIWAqwRsO5Bf++qZJvOvu9Lq9yJPYLu0RU/IOy6Vtrc8auGkMRZtEcpt4
         FFUL4Z20mVpAUMcl2F8Fi8wbT+a+QLXj8Nd3vcERKVRMmsw0BTr0DdNlvfq0slr90lAM
         FiOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=zOZ4bAutApHMupyu+IOmXqdvtYeN5jGA6W8fXAeu+rI=;
        fh=nk3dn+yJFR3ox/jeYcIMmR+YUs8gsGL2srPUXPLRg6E=;
        b=DfJTwfTbuu9EUOSypYXSxmXh2SddpWwV2J3Q8ntNmbZQoKyZc54MWctQHsP/+rsfUB
         cRhn1dGy2D4kFMMhjhlbwATHjhVwNXZjtmavgqRXcsS4PNEeoZuE9uRldzUQLlhm/tXB
         78XTxjEVVj7U15AByfBCxNIMfHEuxWfA44U+VrkDvGcIhsS2iQZqJONKdNVm5k3lfV0B
         tk+QK1qQaTmuqTpNwXJ62vEM60L4LLY981iH9Jn74sMXAmGnjLqZbWavMkhSDwsW/AxU
         YLpYwJEBOvRN8PtwvR5fFNZzXdMD3qVO1wGC5DN/p+t3P5haeBgxmfbmQNP8huxlYB2s
         HJfw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=RgGAtY1F;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com. [2607:f8b0:4864:20::a29])
        by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-301535f9ec1si343082a91.1.2025.03.16.13.52.58
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 16 Mar 2025 13:52:58 -0700 (PDT)
Received-SPF: pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) client-ip=2607:f8b0:4864:20::a29;
Received: by mail-vk1-xa29.google.com with SMTP id 71dfb90a1353d-523efb24fb9so1427507e0c.3
        for <bitcoindev@googlegroups.com>; Sun, 16 Mar 2025 13:52:58 -0700 (PDT)
X-Gm-Gg: ASbGncvzTrYhWE/v0wduLV6dbwgk29Kmutb+s+oIFyutPOG014s1MewFdcI6ZFdNiIy
	L5uXRfix5fwv7HSubcwjxx8x5fx3KR94IAXdh3q0epR5c3eo6wHJP1Rfh5EvjUNRZXgW8kQUVC2
	1CEEOeFqddKcAnyf26ZXaajh6EwTvGMbt+xmv6
X-Received: by 2002:a05:6102:2ac7:b0:4c1:a049:27c7 with SMTP id
 ada2fe7eead31-4c383163e85mr6652781137.13.1742158377370; Sun, 16 Mar 2025
 13:52:57 -0700 (PDT)
MIME-Version: 1.0
References: <CALkkCJY=dv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ@mail.gmail.com>
 <CAJDmzYw-Z2nB3BvSnuCT2OF+ahd-kbVrYauM_cZgmDytPYVfpA@mail.gmail.com>
In-Reply-To: <CAJDmzYw-Z2nB3BvSnuCT2OF+ahd-kbVrYauM_cZgmDytPYVfpA@mail.gmail.com>
From: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Date: Sun, 16 Mar 2025 21:52:47 +0100
X-Gm-Features: AQ5f1JpEaYbM60WSJVsT76OFAY1-FPOaSTVT07PocnrfYioTP8bfEsVA1f0mbfw
Message-ID: <CALkkCJZ6cT=9kq+=mSmkgFY+6x3zxTwo196crOOxTkFWq8w3vw@mail.gmail.com>
Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure
To: Agustin Cruz <agustin.cruz@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000039cdef06307bdb9d"
X-Original-Sender: martin.habovstiak@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=RgGAtY1F;       spf=pass
 (google.com: domain of martin.habovstiak@gmail.com designates
 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

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

Antoine, "in addition to making spending old outputs invalid on their own,
a rule which dictates they may only be spent along with a QR output at
least X blocks old."

yes, this is what I meant but also the QR output must contain the
commitment. This rule makes it not "a race". The attacker cannot make the
commitment before knowing the private key and cannot reverse deep chain.

Augustin, you understand it correctly. Sadly, the dilemma is only mitigated
for hashed keys, not revealed ones.

1. we would presumably bump segwit version, so we can do whatever we like.
I assume it'd be something similar to today's Annex but there are likely
more ways to do it with their pros and cons. I don't think these details
matter much today. But it's certainly possible.
2. of course, soft fork would be required but it will be anyway to deploy a
QR signing algo. And I don't think anything saving coins from certain loss
will be contentious. :)
The changes would need to identify inputs using secp256k1 verification and
look up the commitments in the other inputs. Also they'd need to check how
deep the spent inputs are.

D=C5=88a ne 16. 3. 2025, 20:03 Agustin Cruz <agustin.cruz@gmail.com> nap=C3=
=ADsal(a):

> Hi Martin,
>
> Your approach of using a committed QR signature to =E2=80=9Canchor=E2=80=
=9D the spending
> of hashed keys is intriguing. If I understand correctly, the idea is:
> - A user commits to a QR signature in a first transaction (Tx1), proving
> ownership of the QR private key without exposing vulnerable data.
> - Later, they spend both the old P2PKH output and the QR output together
> (Tx2), revealing the QR signature, with rules ensuring the old output can=
=E2=80=99t
> be spent independently.
> - This forces an attacker to either forge a QR signature (infeasible with
> a quantum-resistant scheme) or rewind the chain past Tx1=E2=80=99s confir=
mation
> (infeasible with sufficient depth).
>
> This seems to provide a solid defense against quantum theft, assuming the
> QR scheme holds up and the blockchain remains secure. I also like how it
> mitigates the =E2=80=9Ctheft vs. freeze=E2=80=9D dilemma. Temporary freez=
ing is indeed less
> catastrophic than permanent loss, and avoiding reputational damage is
> crucial.
>
> To better understand how this would work, I have two questions:
>
> 1. How would the QR signature commitment be encoded and verified in the
> script?. Would this require new opcodes or script functionality to check
> the commitment when spending?
>
> 2. How would you enforce that the old P2PKH output can only be spent with
> the QR output? Would this need a soft fork, and if so, what consensus
> changes would be required?
>
> Regards,
> Agust=C3=ADn
>
> El dom, 16 de mar de 2025, 3:31=E2=80=AFp. m., Martin Habov=C5=A1tiak <
> martin.habovstiak@gmail.com> escribi=C3=B3:
>
>> Hello list,
>>
>> this is somewhat related to Jameson's recent post but different enough t=
o
>> warrant a separate topic.
>>
>> As you have probably heard many times and even think yourself, "hashed
>> keys are not actually secure, because a quantum attacker can just snatch
>> them from mempool". However this is not strictly true.
>>
>> It is possible to implement fully secure recovery if we forbid spending
>> of hashed keys unless done through the following scheme:
>> 0. we assume we have *some* QR signing deployed, it can be done even
>> after QC becomes viable (though not without economic cost)
>> 1. the user obtains a small amount of bitcoin sufficient to pay for 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 prov=
es
>> that the user knew the private key even though the public key wasn't
>> revealed yet.
>> 3. after sufficient number of blocks, the user spends both the old and Q=
R
>> output in a single transaction. Spending requires revealing the
>> previously-committed sigature. Spending the old output alone is invalid.
>>
>> This way, the attacker would have to revert the chain to steal which is
>> assumed impossible.
>>
>> The only weakness I see is that (x)pubs would effectively become private
>> keys. However they already kinda are - one needs to protect xpubs for
>> privacy and to avoid the risk of getting marked as "dirty" by some
>> agencies, which can theoretically render them unspendable. And non-x-pub=
s
>> generally do not leak alone (no reason to reveal them without spending).
>>
>> I think that the mere possibility of this scheme has two important
>> 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
>> has the effect of temporarily freezing coins which is costly and we don'=
t
>> want that but it's not nearly as bad as theft
>> * freezing of *these* coins would be both immoral and extremely dangerou=
s
>> for reputation of Bitcoin (no comments on freezing coins with revealed
>> pubkeys, I haven't made my mind yet)
>>
>> If the time comes I'd be happy to run a soft fork that implements this
>> sanely.
>>
>> Cheers
>>
>> Martin
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-=
byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4=
-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter>
>> .
>>
>

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

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

<div dir=3D"auto"><p dir=3D"ltr" style=3D"font-size:12.8px">Antoine, &quot;=
in addition to making spending old outputs invalid on their own, a rule whi=
ch dictates they may only be spent along with a QR output at least X blocks=
 old.&quot;</p><p dir=3D"ltr" style=3D"font-size:12.8px">yes, this is what =
I meant but also the QR output must contain the commitment. This rule makes=
 it not &quot;a race&quot;. The attacker cannot make the commitment before =
knowing the private key and cannot reverse deep chain.</p><p dir=3D"ltr" st=
yle=3D"font-size:12.8px">Augustin, you understand it correctly. Sadly, the =
dilemma is only mitigated for hashed keys, not revealed ones.</p><p dir=3D"=
ltr" style=3D"font-size:12.8px">1. we would presumably bump segwit version,=
 so we can do whatever we like. I assume it&#39;d be something similar to t=
oday&#39;s Annex but there are likely more ways to do it with their pros an=
d cons. I don&#39;t think these details matter much today. But it&#39;s cer=
tainly possible.<br>2. of course, soft fork would be required but it will b=
e anyway to deploy a QR signing algo. And I don&#39;t think anything saving=
 coins from certain loss will be contentious. :)<br>The changes would need =
to identify inputs using secp256k1 verification and look up the commitments=
 in the other inputs. Also they&#39;d need to check how deep the spent inpu=
ts are.</p></div><br><div class=3D"gmail_quote gmail_quote_container"><div =
dir=3D"ltr" class=3D"gmail_attr">D=C5=88a ne 16. 3. 2025, 20:03 Agustin Cru=
z &lt;<a href=3D"mailto:agustin.cruz@gmail.com">agustin.cruz@gmail.com</a>&=
gt; nap=C3=ADsal(a):<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><p dir=3D"ltr">Hi Martin,</p>
<p dir=3D"ltr">Your approach of using a committed QR signature to =E2=80=9C=
anchor=E2=80=9D the spending of hashed keys is intriguing. If I understand =
correctly, the idea is:<br>
- A user commits to a QR signature in a first transaction (Tx1), proving ow=
nership of the QR private key without exposing vulnerable data.<br>
- Later, they spend both the old P2PKH output and the QR output together (T=
x2), revealing the QR signature, with rules ensuring the old output can=E2=
=80=99t be spent independently.<br>
- This forces an attacker to either forge a QR signature (infeasible with a=
 quantum-resistant scheme) or rewind the chain past Tx1=E2=80=99s confirmat=
ion (infeasible with sufficient depth).</p>
<p dir=3D"ltr">This seems to provide a solid defense against quantum theft,=
 assuming the QR scheme holds up and the blockchain remains secure. I also =
like how it mitigates the =E2=80=9Ctheft vs. freeze=E2=80=9D dilemma. Tempo=
rary freezing is indeed less catastrophic than permanent loss, and avoiding=
 reputational damage is crucial.</p>
<p dir=3D"ltr">To better understand how this would work, I have two questio=
ns:</p><p dir=3D"ltr">1. How would the QR signature commitment be encoded a=
nd verified in the script?. Would this require new opcodes or script functi=
onality to check the commitment when spending?</p><p dir=3D"ltr">2. How wou=
ld you enforce that the old P2PKH output can only be spent with the QR outp=
ut? Would this need a soft fork, and if so, what consensus changes would be=
 required?</p>
<p dir=3D"ltr">Regards,<br>
Agust=C3=ADn </p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">El dom, 16 de mar de 2025, 3:31=E2=80=AFp.=C2=A0m., Martin=
 Habov=C5=A1tiak &lt;<a href=3D"mailto:martin.habovstiak@gmail.com" rel=3D"=
noreferrer noreferrer" target=3D"_blank">martin.habovstiak@gmail.com</a>&gt=
; escribi=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">=
Hello list,<div dir=3D"auto"><br></div><div dir=3D"auto">this is somewhat r=
elated to Jameson&#39;s recent post but different enough to warrant a separ=
ate topic.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As you have p=
robably heard many times and even think yourself, &quot;hashed keys are not=
 actually secure, because a quantum attacker can just snatch them from memp=
ool&quot;. However this is not strictly true.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">It is possible to implement fully secure recovery if =
we forbid spending of hashed keys unless done through the following scheme:=
</div><div dir=3D"auto">0. we assume we have *some* QR signing deployed, it=
 can be done even after QC becomes viable (though not without economic cost=
)</div><div dir=3D"auto">1. the user obtains a small amount of bitcoin suff=
icient to pay for fees via external means, held on a QR script</div><div di=
r=3D"auto">2. the user creates a transaction that, aside from having a usua=
l spendable output also commits to a signature of QR public key. This prove=
s that the user knew the private key even though the public key wasn&#39;t =
revealed yet.</div><div dir=3D"auto">3. after sufficient number of blocks, =
the user spends both the old and QR output in a single transaction. Spendin=
g requires revealing the previously-committed sigature. Spending the old ou=
tput alone is invalid.</div><div dir=3D"auto"><br></div><div dir=3D"auto">T=
his way, the attacker would have to revert the chain to steal which is assu=
med impossible.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The only=
 weakness I see is that (x)pubs would effectively become private keys. Howe=
ver they already kinda are - one needs to protect xpubs for privacy and to =
avoid the risk of getting marked as &quot;dirty&quot; by some agencies, whi=
ch can theoretically render them unspendable. And non-x-pubs generally do n=
ot leak alone (no reason to reveal them without spending).</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">I think that the mere possibility of thi=
s scheme has two important implications:</div><div dir=3D"auto">* the need =
to have &quot;a QR scheme&quot; ready now in case of a QC coming tomorrow i=
s much smaller than previously thought. Yes, doing it too late has the effe=
ct of temporarily freezing coins which is costly and we don&#39;t want that=
 but it&#39;s not nearly as bad as theft</div><div dir=3D"auto">* freezing =
of *these* coins would be both immoral and extremely dangerous for reputati=
on of Bitcoin (no comments on freezing coins with revealed pubkeys, I haven=
&#39;t made my mind yet)</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>If the time comes I&#39;d be happy to run a soft fork that implements this=
 sanely.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Cheers</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Martin</div></div>

<p></p>

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

<p></p>

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

--00000000000039cdef06307bdb9d--