From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 17 Mar 2025 06:37:08 -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 1tuAeR-0003s0-1I for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:37:08 -0700 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-72bd7984706sf962462a34.1 for ; Mon, 17 Mar 2025 06:37:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1742218621; cv=pass; d=google.com; s=arc-20240605; b=TogliYOBteokkNQDqtIVw8kEGLRbcfulp31JzGJRPU5UWEE7JXFOZ0TtsYYAEUQt60 MC3NCrFjzV0Ec9gmvYVu0dYI5x0tZAW74f+EZrPCcnG3v3JVd2HcNDuO2Z25+x+r9HIa xT37zMkv+NT86+jLFGs1HsLjAID+GG8d3cIseH1ViggvTWOMKSv8oKO8bl7a57TRUFGC Y9tBiOjxE3eKMTtMVH6Te+S5X9Lz3Rp2yKl1dVcVFNseMBTC2bwUNKew1s3VjPdnFPKp ftpzlsT/45iVuqQJGk/UEv3bRB2ow8uHOCisyKIgYQLkBH9JYbtCiiy4pluNgMA9hIj2 1xpw== 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=gUjqpepEUsRa4U9zTH1WyVPo8RCKQ2FR8Z4ZJ2ibeQc=; fh=/3M7M09FoZj7aGXM+PySt2lYAkhN4P5Y7hrVSFdNrlo=; b=Wrm4lbcxTYBY2uIHuiKLR6ySAjRvf0eGIGNAxWUhfT4LBCIDMWlfpcV69AN5uTKw0z Y73nLSsGxKocJQFheBIRZQIbGaF+0OeIqIQN8O5bw+zM+fT2ETLTZa2c1/Y/PQ7/gspm 5G9QUvfIhlTdsCnLnfd+S79ahv5P/HAN/GXtxlL3n08wRQ0aAAAKBfe58ygWIhTZ+5wq +LvJVTF5RBZd/QrFKC6Qye7oXzKiogSrzd0FiSa4OXg1RfOEU7Hy4pwtTvdj1z+eVSu1 ho5WUMkNtngh5SYOOI86Qyq9SmXmn6TMVNpV1mEHHoSrsHyjpyaUJ1mOcORtxvoKXT7l u58Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=JFb717b0; spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1742218621; x=1742823421; 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=gUjqpepEUsRa4U9zTH1WyVPo8RCKQ2FR8Z4ZJ2ibeQc=; b=r6eEVeFS0OGHjyNExQsap9irfUKGofwgz6NbMSYInB1cAg0cRsP6+1M9Mjb5gjOUs4 EoA1pERCcLzcwDUicVlDC8Qzn7W9eA9xs8Ezl1WHK7Z1FLV2JuwpjjaLArlZoMrVzGxv fZGHAj3ddynJqMJbUDLw/PfPSVDvVe9LdB7YzSMZV/Gj0X1eVPpEKuXPbdFq1/5F2euZ 8jxqX59YxqsfWIUHkKlEi/kqCc7Y+F2WhBrj7HfC7orU7JyPbFVqLIf4aUPnv/PIP4mc JmszqdsmRiqwZ4F/3GkJdp9eB4R1aLGmYKne26/+BjbYl7Ew5T/X4sonjC3cOUpv6VSw R0VA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742218621; x=1742823421; 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=gUjqpepEUsRa4U9zTH1WyVPo8RCKQ2FR8Z4ZJ2ibeQc=; b=I2oTUpW3YpRpKUy0g5V4mXtJEpXxNVVv1+5JsotK5K7MYVhe+gj+/v4g4YrKu2BUHk IQ/pAAZm12VfGLJQfADaEDgEt+jdFeZqcL1RcM93qRuoUMO/0uJPl4xp4ANF0CK4nvMN 1c761vVaB7AbLzOmRsUXiBTkSH6JTwpOx5q9KjvDUuGhzKO/TP/Cr4gyHtDJyjo1FxE9 7QB4UIsimYjUYdBbAFWJN62UQ2E5BcnK85DXgbmGZcb/SpvNj3cSE915MsZXzEwjVVoE ACqYkPrGUHqq6JB4UYR/1R9vRdTHGZ3C007aLs1JqbJS2LubCg4AetHrJnW29dgYsvV5 2tOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742218621; x=1742823421; 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=gUjqpepEUsRa4U9zTH1WyVPo8RCKQ2FR8Z4ZJ2ibeQc=; b=B4it997/vFKaVacrxUDxmRsQZX47LwTi7nfAWl9ZKZr5fCdBGGPKe1mqpSMOzTCtJ4 Ib5JncPdoYqfyNGwVxgDoBJPq1gMe0Xo86DrZEz4oMKPtz75PZoGqJpBlaqI0SKxcCa9 OCOSgvn4CqhhnhDE6sD8hmdXkCKOSUHCXh7W7smiLSiY5Na5cTDaSrs39GN7+kEWnz73 MJ9+Umhng6WzAR4aXXBr4gl0nOOfbUJJiskbRpScDR+SeDYonA/lmatyW/YfaQ1XcZmO HllYMtP1R9nC1jljmufkb54K7wfJcL+klAglAffVcMFApSFcyimzxb6sTD0FTqICMyhk psWA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUoSoT08ynJyIHQOlFA9PmzhAV5Y4NsVGExDVaPpZsU8/Q3XXZrGeb+aRfU/y5PFntTqYQlqTdu0nS4@gnusha.org X-Gm-Message-State: AOJu0YzxMXO08D/e/MWBoDyLsqaY0uJgkxFgu4icDcK6+fJuVEDBL3pj pfJCZTTs4QcRByF1oVVDFeC2pNs7L0YazAnGUGsRsGb7PIC7kUcg X-Google-Smtp-Source: AGHT+IEm95IjaLe0IJxisra20nFco2j25aGEjLeaKYZTGEXo8idXMJxFEOsZRLXREziuL7GJ/R0jBg== X-Received: by 2002:a05:6830:448b:b0:72b:955a:852c with SMTP id 46e09a7af769-72bbc46737bmr7300778a34.11.1742218621422; Mon, 17 Mar 2025 06:37:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJgmJ9x/2kqrloBhHpWFZayO+KPFvj/slTCl3RMTLCDTg== Received: by 2002:a4a:dd85:0:b0:602:af0:7fc2 with SMTP id 006d021491bc7-6020af094e1ls65257eaf.0.-pod-prod-08-us; Mon, 17 Mar 2025 06:36:50 -0700 (PDT) X-Received: by 2002:a05:6808:2008:b0:3fa:3a0:137b with SMTP id 5614622812f47-3fdf036469cmr5625993b6e.29.1742218610119; Mon, 17 Mar 2025 06:36:50 -0700 (PDT) Received: by 2002:a05:600c:4f03:b0:43c:fe99:f0d4 with SMTP id 5b1f17b1804b1-43d1f0118a2ms5e9; Sun, 16 Mar 2025 12:03:37 -0700 (PDT) X-Received: by 2002:a05:6000:1a88:b0:391:487f:280b with SMTP id ffacd0b85a97d-3971d23520amr10574572f8f.10.1742151815731; Sun, 16 Mar 2025 12:03:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1742151815; cv=none; d=google.com; s=arc-20240605; b=BLZMFCEUnlzVPNY9ZErE5rGKCZY5zCdJuxon7eqyqCjbDKwvdWjBhjEoRxlcVW3Fnc KK+7XA+2dt7coNTpeuSGPDaaEH3nNqMkXeDWx634pcCtK3iUnghJBaUC1PRIGx9hUJYi QDKiL76W/FLQ0J1s5k+LSUCJ4Ser48xwZgtk2wmVOSfNvGb5lxxL2HjSfuOXLaN28zOz ZDa1gj4tZhrei2I392ay99EkO5mCMJwHNa+j0t+vdfn859SZVkehp9aoEC2ngh0sb8vM j1oTLEgI4E3y2Vutsgvg85qocuORADTStJIzSYcRQabRnqRAgz8L80P+t5SgD2SjVXIS crUA== 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=Mowg0lo+NH58WwItm477wH7b0WXtC3ow6LPPS+ZeQ7Y=; fh=FHPCOD3vptmuEQg9drujpZ488lCS6X5YsZgbHrlMbXI=; b=C/y3NwyXKvvbdz0G8miSgcv111itLNfVbCJljmYUueS3/8uyRWKFgg7rA/yJbOGki8 N1Fp2fwHezgTsBQD9LNWeln6s6y4Fc0AxmYZ7XfOsW36gUMP4zq32IEoGBgx3S6f56j/ DWCWj43qWU7hQThliwvPehEWXLA604delAMTgX3hvtK6dt7mjKbbj1j0I9SY/MRLZuSD q2lK4Tt/HasBzRxox0kQesV5D6DdIEXNnTLmznpAz/Dm79OAFuxrQnjt2z+gzidx9WJf StLhYIn8xWb/sXH2y8RBItuqOcqK1BOT3N6Vhlu2JwGzAJxqREUNK+ukpjYeYgKe7w82 PQ+g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=JFb717b0; spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com. [2a00:1450:4864:20::12e]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-395ca77d272si272075f8f.6.2025.03.16.12.03.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Mar 2025 12:03:35 -0700 (PDT) Received-SPF: pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) client-ip=2a00:1450:4864:20::12e; Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-5493b5bc6e8so3929022e87.2 for ; Sun, 16 Mar 2025 12:03:35 -0700 (PDT) X-Gm-Gg: ASbGncvNGvCt5ZEHhFilPyVBO6EJxgFG5eIDZjIA0kB5AzUVoIwMGZkQnrSxOStGFOF MKd4G2bKJ2vYE1pxTsRocKbmApS8H5/jCmIQIH653uoUZ0TShOXmaUEtPLyEsG5lLocJyzsW6LW 9WFtZsbLFZdkgDJtQBXYD05VK5tC9w0K48xoqvKaU= X-Received: by 2002:a05:6512:b0d:b0:545:154:52b0 with SMTP id 2adb3069b0e04-549c3911fdamr4283931e87.22.1742151814591; Sun, 16 Mar 2025 12:03:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Agustin Cruz Date: Sun, 16 Mar 2025 16:03:22 -0300 X-Gm-Features: AQ5f1JopmhTC28uqOCdDbi1W9y8eWhZybx6YvXWcqYHHZIv6IIMrMa1QtoJxMuU Message-ID: Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000000dbea606307a542c" X-Original-Sender: agustin.cruz@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=JFb717b0; spf=pass (google.com: domain of agustin.cruz@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=agustin.cruz@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --0000000000000dbea606307a542c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 confirmati= on (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 freezin= g 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 to > 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 o= f > hashed keys unless done through the following scheme: > 0. we assume we have *some* QR signing deployed, it can be done even afte= r > 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 prove= s > 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 QR > 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-pubs > 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 tomorro= w > 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 th= at > but it's not nearly as bad as theft > * freezing of *these* coins would be both immoral and extremely dangerous > 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 Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-b= yGOjME3Jt2DRr20yZqMmdJUnQ%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/= CAJDmzYw-Z2nB3BvSnuCT2OF%2Bahd-kbVrYauM_cZgmDytPYVfpA%40mail.gmail.com. --0000000000000dbea606307a542c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Martin,

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:
- A user commits to a QR signature in a first transaction (Tx1), proving ow= nership of the QR private key without exposing vulnerable data.
- 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.
- 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).

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.

To better understand how this would work, I have two questio= ns:

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?

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?

Regards,
Agust=C3=ADn


El dom, 16 de mar de 2025, 3:31=E2=80=AFp.=C2=A0m., Martin= Habov=C5=A1tiak <martin.habovstiak@gmail.com> escribi= =C3=B3:
Hello lis= t,

this is somewhat related to= Jameson's recent post but different enough to warrant a separate topic= .

As you have probably h= eard 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 d= one 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 spendab= le output also commits to a signature of QR public key. This proves that th= e 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 QR output in a single transaction. Spending require= s revealing the previously-committed sigature. Spending the old output alon= e is invalid.

This way, = the attacker would have to revert the chain to steal which is assumed impos= sible.

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 th= eoretically render them unspendable. And non-x-pubs generally do not leak a= lone (no reason to reveal them without spending).
I think that the mere possibility of this scheme = has two important implications:
* the need to have &= quot;a QR scheme" ready now in case of a QC coming tomorrow is much sm= aller than previously thought. Yes, doing it too late has the effect of tem= porarily freezing coins which is costly and we don't want that but it&#= 39;s not nearly as bad as theft
* freezing of *these= * coins would be both immoral and extremely dangerous for reputation of Bit= coin (no comments on freezing coins with revealed pubkeys, I haven't ma= de my mind yet)

If the t= ime comes I'd be happy to run a soft fork that implements this sanely.<= /div>

Cheers

Martin

--
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 bitcoindev+unsubscribe@googlegroups= .com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALkkC= JY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.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/CAJDmzYw-Z2nB3BvSnuCT2OF%2Bahd-kbVrYauM_cZgmDytPYVfpA%40ma= il.gmail.com.
--0000000000000dbea606307a542c--