From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 14 Jun 2024 07:31:00 -0700 Received: from mail-yb1-f187.google.com ([209.85.219.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sI7xE-00085D-7G for bitcoindev@gnusha.org; Fri, 14 Jun 2024 07:31:00 -0700 Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-dfec7058deesf4269487276.2 for ; Fri, 14 Jun 2024 07:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1718375454; x=1718980254; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=Z5DVh7zpHR8LBXwsTgTejPoihBxJsxRDTg/mWBHBsU8=; b=gl+5pxUN1xT0aY3kpMEw832v/KW79fjqxtA7quKyJYO7MEP87ZJt8aZeTfytvo37oW qAInKlB1+Jl6i82HJ73GiGYA3upU0YjkHQDAsfCKJB04EAK0Uee2eKAbwz/CeRelJkdz zTDUb6chi0THqVCrlrU+PMRkvNPcWeX9MrwILBW78knyvUwelPrEFJIwAxIwcXhuiuX2 KJx9viyOWCIlUjx8FKoH1vCF+4lDYy0bjyLtcwNdRIYH46jPzEa8WKvf23x+By8DkZoZ aDarLc0Klq/sQESQc1lzyOyCTfXmcCsQSerDF0EXZkn8NGLr86LjdBztAb8gaeGfCwlm fRHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718375454; x=1718980254; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=Z5DVh7zpHR8LBXwsTgTejPoihBxJsxRDTg/mWBHBsU8=; b=GD8v15nvqZGOvoEMXILl2m6ms0jAq5wLbEjdDcj8G2FtnOQe5L/EdI/2106LSZKg/m gXK9LFyuIHmi4wGyC4ZBRncn8MZUwFDeZZyVM+rUsrj+2DLSq5qQ1f+C3XtRGFZC4V0o hdqjUfuv/+qyk+AhNIoTbutE/j7fDomL0pVgPJ7EAARLuYbze9XiPrJ+Rgdki5Tj/X2C 6V8xQYS/fo1WTL8dWWFVdkugGqEc4CS59MQkqeKCfxVj49DpGnZtYeeILEHpPeqg8+2/ GIMR169lAttqOI041CTyNe8WXxAynEEog6BTk90ByzbmtYoat/5goJrfB4iStYc1T4JI C/eA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW+2/SWNRMpRlkCuRkg9nE34MJK5bsf6w0dHBmjZ3aeN7v7DE6AbbTf8VI+H0bFC79Hn9y3r9uysC4KCKyKgnPITPUzCOI= X-Gm-Message-State: AOJu0YwBO3w+Wbl0bQUZyFrRip3VG+xJyHX9iiSpTPNhYZVaIihRghQd LDbDBy+twaKbfSKumatxHEohUNOUUPHFfgEHOEcUqNo2natoquwb X-Google-Smtp-Source: AGHT+IEWMa6oPGk/DH7f7ZJ3ZGojjpJxd5IiDyYNdSmFYZWeuI3ka3r8IjGgBQQPPHF30EmEUBAHMQ== X-Received: by 2002:a25:bfce:0:b0:dfa:c4b8:630e with SMTP id 3f1490d57ef6-dff153b2176mr2655792276.33.1718375453919; Fri, 14 Jun 2024 07:30:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1249:b0:dfe:54e6:8233 with SMTP id 3f1490d57ef6-dfefe6e2bacls3070792276.0.-pod-prod-08-us; Fri, 14 Jun 2024 07:30:51 -0700 (PDT) X-Received: by 2002:a05:690c:3581:b0:61b:e73d:bea2 with SMTP id 00721157ae682-63223d3b7c4mr6336177b3.5.1718375451639; Fri, 14 Jun 2024 07:30:51 -0700 (PDT) Received: by 2002:a81:be0b:0:b0:62c:c6a5:525b with SMTP id 00721157ae682-6321c1acd02ms7b3; Fri, 14 Jun 2024 07:28:31 -0700 (PDT) X-Received: by 2002:a05:690c:d81:b0:62c:f01d:3470 with SMTP id 00721157ae682-632248103f6mr6536647b3.6.1718375310477; Fri, 14 Jun 2024 07:28:30 -0700 (PDT) Date: Fri, 14 Jun 2024 07:28:30 -0700 (PDT) From: Hunter Beast To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <62fd28ab-e8b5-4cfc-b5ae-0d5a033af057n@googlegroups.com> Subject: [bitcoindev] Re: Proposing a P2QRH BIP towards a quantum resistant soft fork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_35590_372245926.1718375310167" X-Original-Sender: hunter@surmount.systems 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.7 (/) ------=_Part_35590_372245926.1718375310167 Content-Type: multipart/alternative; boundary="----=_Part_35591_1656874458.1718375310167" ------=_Part_35591_1656874458.1718375310167 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good points. I like your suggestion for a SPHINCS+, just due to how mature= =20 it is in comparison to SQIsign. It's already in its third round and has=20 several standards-compliant implementations, and it has an actual=20 specification rather than just a research paper. One thing to consider is= =20 that NIST-I round 3 signatures are 982 bytes in size, according to what I= =20 was able to find in the documents hosted by the SPHINCS website. https://web.archive.org/web/20230711000109if_/http://sphincs.org/data/sphin= cs+-round3-submission-nist.zip One way to handle this is to introduce this as a separate address type than= =20 SQIsign. That won't require OP_CAT, and I do want to keep this soft fork=20 limited in scope. If SQIsign does become significantly broken, in this=20 hopefully far future scenario, I might be supportive of an increase in the= =20 witness discount. Also, I've made some additional changes based on your feedback on X. You=20 can review them here if you so wish: https://github.com/cryptoquick/bips/pull/5/files?short_path=3D917a32a#diff-= 917a32a71b69bf62d7c85dfb13d520a0340a30a2889b015b82d36411ed45e754 On Friday, June 14, 2024 at 8:15:29=E2=80=AFAM UTC-6 Pierre-Luc Dallaire-De= mers=20 wrote: > SQIsign is blockchain friendly but also very new, I would recommend addin= g=20 > a hash-based backup key in case an attack on SQIsign is found in the futu= re=20 > (recall that SIDH broke over the span of a weekend=20 > https://eprint.iacr.org/2022/975.pdf). > Backup keys can be added in the form of a Merkle tree where one branch=20 > would contain the SQIsign public key and the other the public key of the= =20 > recovery hash-based scheme. For most transactions it would only add one b= it=20 > to specify the SQIsign branch. > The hash-based method could be Sphincs+, which is standardized by NIST bu= t=20 > requires adding extra code, or Lamport, which is not standardized but can= =20 > be verified on-chain with OP-CAT. > > On Sunday, June 9, 2024 at 12:07:16=E2=80=AFp.m. UTC-4 Hunter Beast wrote= : > >> The motivation for this BIP is to provide a concrete proposal for adding= =20 >> quantum resistance to Bitcoin. We will need to pick a signature algorith= m,=20 >> implement it, and have it ready in event of quantum emergency. There wil= l=20 >> be time to adopt it. Importantly, this first step is a more substantive= =20 >> answer to those with concerns beyond, "quantum computers may pose a thre= at,=20 >> but we likely don't have to worry about that for a long time". Bitcoin= =20 >> development and activation is slow, so it's important that those with lo= w=20 >> time preference start discussing this as a serious possibility sooner=20 >> rather than later. >> >> This is meant to be the first in a series of BIPs regarding a=20 >> hypothetical "QuBit" soft fork. The BIP is intended to propose concrete= =20 >> solutions, even if they're early and incomplete, so that Bitcoin develop= ers=20 >> are aware of the existence of these solutions and their potential. >> >> This is just a rough draft and not the finished BIP. I'd like to validat= e=20 >> the approach and hear if I should continue working on it, whether seriou= s=20 >> changes are needed, or if this truly isn't a worthwhile endeavor right n= ow. >> >> The BIP can be found here: >> https://github.com/cryptoquick/bips/blob/p2qrh/bip-p2qrh.mediawiki >> >> Thank you for your time. >> >> --=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 on the web visit https://groups.google.com/d/msgid/= bitcoindev/d78f5dc4-a72d-4da4-8a24-105963155e4dn%40googlegroups.com. ------=_Part_35591_1656874458.1718375310167 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good points. I like your suggestion for a SPHINCS+, just due to how mature = it is in comparison to SQIsign. It's already in its third round and has sev= eral standards-compliant implementations, and it has an actual specificatio= n rather than just a research paper. One thing to consider is that NIST-I r= ound 3 signatures are 982 bytes in size, according to what I was able to fi= nd in the documents hosted by the SPHINCS website.
https://web.archive.= org/web/20230711000109if_/http://sphincs.org/data/sphincs+-round3-submissio= n-nist.zip

One way to handle this is to introduc= e this as a separate address type than SQIsign. That won't require OP_CAT, = and I do want to keep this soft fork limited in scope. If SQIsign does beco= me significantly broken, in this hopefully far future scenario, I might be = supportive of an increase in the witness discount.

Also, I've made some additional changes based on your feedback on X. You= can review them here if you so wish:
https://github.com/cryptoqu= ick/bips/pull/5/files?short_path=3D917a32a#diff-917a32a71b69bf62d7c85dfb13d= 520a0340a30a2889b015b82d36411ed45e754

On Friday, June 14, 202= 4 at 8:15:29=E2=80=AFAM UTC-6 Pierre-Luc Dallaire-Demers wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left:= 1px solid rgb(204, 204, 204); padding-left: 1ex;">SQIsign is blockchain fr= iendly but also very new, I would recommend adding a hash-based backup key = in case an attack on SQIsign is found in the future (recall that SIDH broke= over the span of a weekend=C2=A0https://eprint.iacr.org/2022/975.pdf).
Backup keys can be ad= ded in the form of a Merkle tree where one branch would contain the SQIsign= public key and the other the public key of the recovery hash-based scheme.= For most transactions it would only add one bit to specify the SQIsign bra= nch.
The hash-based method could be Sphincs+, which is standardiz= ed by NIST but requires adding extra code, or Lamport, which is not standar= dized but can be verified on-chain with OP-CAT.

On Sunday, June 9, 2024= at 12:07:16=E2=80=AFp.m. UTC-4 Hunter Beast wrote:
The motivation for this BIP is to provide a c= oncrete proposal for adding quantum resistance to Bitcoin. We will need to = pick a signature algorithm, implement it, and have it ready in event of qua= ntum emergency. There will be time to adopt it. Importantly, this first ste= p is a more substantive answer to those with concerns beyond, "quantum= computers may pose a threat, but we likely don't have to worry about t= hat for a long time". Bitcoin development and activation is slow, so i= t's important that those with low time preference start discussing this= as a serious possibility sooner rather than later.

This is meant to= be the first in a series of BIPs regarding a hypothetical "QuBit"= ; soft fork. The BIP is intended to propose concrete solutions, even if the= y're early and incomplete, so that Bitcoin developers are aware of the = existence of these solutions and their potential.

This is just a rou= gh draft and not the finished BIP. I'd like to validate the approach an= d hear if I should continue working on it, whether serious changes are need= ed, or if this truly isn't a worthwhile endeavor right now.
The BIP can be found here:


--
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 on the web visit https://groups.google.com/d/msg= id/bitcoindev/d78f5dc4-a72d-4da4-8a24-105963155e4dn%40googlegroups.com.=
------=_Part_35591_1656874458.1718375310167-- ------=_Part_35590_372245926.1718375310167--