Delivery-date: Fri, 14 Jun 2024 07:31:00 -0700
Sender: bitcoindev@googlegroups.com
Date: Fri, 14 Jun 2024 07:28:30 -0700 (PDT)
From: Hunter Beast <hunter@surmount.systems>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <d78f5dc4-a72d-4da4-8a24-105963155e4dn@googlegroups.com>
In-Reply-To: <b3561407-483e-46cd-b5e9-d6d48f8dca93n@googlegroups.com>
References: <62fd28ab-e8b5-4cfc-b5ae-0d5a033af057n@googlegroups.com>
 <b3561407-483e-46cd-b5e9-d6d48f8dca93n@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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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.<div>https://web.archive.=
org/web/20230711000109if_/http://sphincs.org/data/sphincs+-round3-submissio=
n-nist.zip</div><div><br /></div><div>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.<br /><div><br /></div><d=
iv>Also, I've made some additional changes based on your feedback on X. You=
 can review them here if you so wish:</div><div>https://github.com/cryptoqu=
ick/bips/pull/5/files?short_path=3D917a32a#diff-917a32a71b69bf62d7c85dfb13d=
520a0340a30a2889b015b82d36411ed45e754<br /><br /></div></div><div class=3D"=
gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Friday, June 14, 202=
4 at 8:15:29=E2=80=AFAM UTC-6 Pierre-Luc Dallaire-Demers wrote:<br/></div><=
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=A0<a href=3D"https://eprint.iacr.org/2022/97=
5.pdf" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://w=
ww.google.com/url?hl=3Den&amp;q=3Dhttps://eprint.iacr.org/2022/975.pdf&amp;=
source=3Dgmail&amp;ust=3D1718461116324000&amp;usg=3DAOvVaw23W-cVEDFQb6VEQyR=
P7YOf">https://eprint.iacr.org/2022/975.pdf</a>).<div>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.</div><div>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.<br><br></div><div class=3D"=
gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Sunday, June 9, 2024=
 at 12:07:16=E2=80=AFp.m. UTC-4 Hunter Beast wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">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, &quot;quantum=
 computers may pose a threat, but we likely don&#39;t have to worry about t=
hat for a long time&quot;. Bitcoin development and activation is slow, so i=
t&#39;s important that those with low time preference start discussing this=
 as a serious possibility sooner rather than later.<br><br>This is meant to=
 be the first in a series of BIPs regarding a hypothetical &quot;QuBit&quot=
; soft fork. The BIP is intended to propose concrete solutions, even if the=
y&#39;re early and incomplete, so that Bitcoin developers are aware of the =
existence of these solutions and their potential.<br><br>This is just a rou=
gh draft and not the finished BIP. I&#39;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&#39;t a worthwhile endeavor right now.<br><div><br=
></div><div>The BIP can be found here:</div><div><a href=3D"https://github.=
com/cryptoquick/bips/blob/p2qrh/bip-p2qrh.mediawiki" rel=3D"nofollow" targe=
t=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp=
;q=3Dhttps://github.com/cryptoquick/bips/blob/p2qrh/bip-p2qrh.mediawiki&amp=
;source=3Dgmail&amp;ust=3D1718461116324000&amp;usg=3DAOvVaw1ayxKakQ3Y01Voi6=
O6fvBL">https://github.com/cryptoquick/bips/blob/p2qrh/bip-p2qrh.mediawiki<=
/a><br></div><div><br></div><div>Thank you for your time.</div><div><br></d=
iv></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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/d78f5dc4-a72d-4da4-8a24-105963155e4dn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/d78f5dc4-a72d-4da4-8a24-105963155e4dn%40googlegroups.com</a>.=
<br />

------=_Part_35591_1656874458.1718375310167--

------=_Part_35590_372245926.1718375310167--