From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 16 Jun 2024 18:24:57 -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 <bitcoindev+bncBC3PT7FYWAMRBYFAX2ZQMGQEWJ2T77Q@googlegroups.com>) id 1sJ17A-0000c4-F9 for bitcoindev@gnusha.org; Sun, 16 Jun 2024 18:24:57 -0700 Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-dff2f9f01f7sf2538067276.1 for <bitcoindev@gnusha.org>; Sun, 16 Jun 2024 18:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1718587490; x=1719192290; 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=1J+/ci698KkDOH8Vb/iKZWy8oMrAHhoHGxdxqhBz1SU=; b=BzTYpg567PiMzkCdFQ4kUJQdChxR2jVtBtQptZ6s2FcYmIgPYPyrKEpLxw8I+1Df+X ShrmmvExe5lKW215VTtb7tEMbumjiJlkuj5RWjOiOWnpz5hc700XkKS7caZtOdLwLzWE 9HG0un1H8/hDMYV+HbFyDMkab7hDjesht/1ZVbPYZlJmEZRurPvmP3bGNiwEv5lrvOQb TLCPGhNe/3ng1zeZe200W0w0jM8VkI2LOh7p0HThflQGnSCldQxUdfAYChnBnXmEw1TK WPHEeJp/CRDgHUsll23jWxO4qq3t8bN4qvToo60yW8VX5gwJaSMvtkG7pOZQg7hXBjze V5FA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718587490; x=1719192290; 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:from:to:cc :subject:date:message-id:reply-to; bh=1J+/ci698KkDOH8Vb/iKZWy8oMrAHhoHGxdxqhBz1SU=; b=m+yHUDIwG1PbjrC2b/pB4+qAVkqDnCmYEJj41wBp4v2JGqtVuvxNHhpqZ651DvYRbe 2Wzna20PdlBBrVMLxRPpuYMLBhDs+6At93sRr/Yro4pO3dLIGSeCok+/xlqdzInJHL9a rGaXyCQw1L8WrE8TsNPjEW0Tq/uNZp0t7YYqsBYngcprQtz7AMMGlQs9lZmy92GxM/xF +t49xFOkgM7iLqWGV2wD/0iE2Uilk5eAeuUMQov4A0TT/kFgSbQnsvCpxJjNNQhAfF3a j9MC1oXaX/PN1/F+Ucvvke60iuZlzbKoqJUvQPuGk/zzZ7p7Z5F1EiOBet7S3/GDdCDP BULw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718587490; x=1719192290; 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=1J+/ci698KkDOH8Vb/iKZWy8oMrAHhoHGxdxqhBz1SU=; b=RRnFfDXZ63M2ZevJZCyIVgd/Cl58qjDytcJFokgjFxN+yana3Ivq8QiRgaHxpyldjS Gc0N9m8n5xlolJqFc3c+RkR6NDFa+zzxLXRy+py3YAjkR3/lQX3wOJnG7oqKdxHHnb29 Pz8EdmCxv84QcQ/c0C+Xr7Qnu6JIhH50YFtRyQrGxhbWZs8iWPHPPKN3SEJyPv185Jdb FvTMRhejyaxZuwhLVqCVfHpZQG0kZkLPmxSlh46IwPailn9nDZYvV1JI22JCM36HXhpw WlIb3qR9ReS/CYBLXDC4obtq+n6eMEbSHkTjRJNrMoVaUtZQi72a/K+yGUyvUsGfSN+O L2Lg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWvhK+UjaZgHXTmUF+r2/ZFj5fTSOPLY8n/P7IrqFAYNHMuuDL+aBj31A6xogbSwE2asRSqAMgcwexFOl3QUWAJC/6VPjc= X-Gm-Message-State: AOJu0YwS6VJTmUf+t6mzJ49++glaZvy8hPNfYaxouIZ4w4yqjpfXahX+ dL5YslZnXuYYWEqk0Iu183BTKzCyuSeZsdOgRFtfiBICPxHuMskq X-Google-Smtp-Source: AGHT+IF8QVkWE2w/W+BBAI3urqDOREZFAp5QsA+R7/5MaL5fePyXrdzhb9Bke8Fpm+S9lwOaXlhKow== X-Received: by 2002:a05:6902:1201:b0:dff:2a78:fbe8 with SMTP id 3f1490d57ef6-dff2a78fde8mr5707218276.49.1718587489612; Sun, 16 Jun 2024 18:24:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1505:b0:dff:7a3:b0d with SMTP id 3f1490d57ef6-dff07a311bfls4983529276.0.-pod-prod-07-us; Sun, 16 Jun 2024 18:24:48 -0700 (PDT) X-Received: by 2002:a05:6902:2b10:b0:dfa:5a23:379e with SMTP id 3f1490d57ef6-dff153cd4b2mr3114081276.4.1718587488025; Sun, 16 Jun 2024 18:24:48 -0700 (PDT) Received: by 2002:a0d:f244:0:b0:620:26bb:319f with SMTP id 00721157ae682-6321bacb6c0ms7b3; Sun, 16 Jun 2024 18:07:47 -0700 (PDT) X-Received: by 2002:a05:690c:700e:b0:627:a962:4252 with SMTP id 00721157ae682-63224613c12mr21689127b3.7.1718586466437; Sun, 16 Jun 2024 18:07:46 -0700 (PDT) Date: Sun, 16 Jun 2024 18:07:46 -0700 (PDT) From: Antoine Riard <antoine.riard@gmail.com> To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> Message-Id: <87b4e402-39d8-46b0-8269-4f81fa501627n@googlegroups.com> In-Reply-To: <d78f5dc4-a72d-4da4-8a24-105963155e4dn@googlegroups.com> References: <62fd28ab-e8b5-4cfc-b5ae-0d5a033af057n@googlegroups.com> <b3561407-483e-46cd-b5e9-d6d48f8dca93n@googlegroups.com> <d78f5dc4-a72d-4da4-8a24-105963155e4dn@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_200558_411727636.1718586466160" X-Original-Sender: antoine.riard@gmail.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 (/) ------=_Part_200558_411727636.1718586466160 Content-Type: multipart/alternative; boundary="----=_Part_200559_122869671.1718586466160" ------=_Part_200559_122869671.1718586466160 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hunter Beast, I think any post-quantum upgrade signature algorithm upgrade proposal would= =20 grandly benefit to have Shor's based practical attacks far more defined in the Bitcoin context. As= =20 soon you start to talk about quantum computers there is no such thing as a "quantum computer" though a= =20 wide array of architectures based on a range of technologies to encode qubits on nanoscale physical=20 properties. This is not certain that any Shor's algorithm variant works smoothly=20 independently of the quantum computer architecture considered (e.g gate frequency, gate infidelity, cooling=20 energy consumption) and I think it's an interesting open game-theory problem if you can concentrate a sufficiant= =20 amount of energy before any coin owner moves them in consequence (e.g seeing a quantum break in the=20 mempool and reacting with a counter-spend). In my opinion, one of the last time the subject was addressed on the=20 mailing list, the description of the state of the quantum computer field was not realistic and get into risk=20 characterization hyperbole talking about "super-exponential rate" (when indeed there is no empirical=20 realization that distinct theoretical advance on quantum capabilities can be combined with each other) [1]. On your proposal, there is an immediate observation which comes to mind,=20 namely why not using one of the algorithm (dilthium, sphincs+, falcon) which has been through the 3 rounds of NIST=20 cryptanalysis. Apart of the signature size, which sounds to be smaller, in a network of full-nodes any PQ signature=20 algorithm should have reasonable verification performances. Lastly, there is a practical defensive technique that can be implemented=20 today by coin owners to protect in face of hyptothetical quantum adversaries. Namely setting spending scripts to=20 request an artificially inflated witness stack, as the cost has to be burden by the spender. I think one can easily do that= =20 with OP_DUP and OP_GREATERTHAN and a bit of stack shuffling. While the efficiency of this technique is limited by=20 the max consensus size of the script stack=20 (`MAX_STACK_SIZE`) and the max consensus size of stack element=20 (`MAX_SCRIPT_ELEMENT_SIZE`), this adds an additional "scarce coins" pre-requirement on the quantum adversarise to succeed.=20 Shor's algorithm is only defined under the classic ressources of computational complexity, time and space. Best, Antoine [1] https://freicoin.substack.com/p/why-im-against-taproot Le vendredi 14 juin 2024 =C3=A0 15:30:54 UTC+1, Hunter Beast a =C3=A9crit : > Good points. I like your suggestion for a SPHINCS+, just due to how matur= e=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/sph= incs+-round3-submission-nist.zip > > One way to handle this is to introduce this as a separate address type=20 > than SQIsign. That won't require OP_CAT, and I do want to keep this soft= =20 > fork limited in scope. If SQIsign does become significantly broken, in th= is=20 > hopefully far future scenario, I might be supportive of an increase in th= e=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#dif= f-917a32a71b69bf62d7c85dfb13d520a0340a30a2889b015b82d36411ed45e754 > > On Friday, June 14, 2024 at 8:15:29=E2=80=AFAM UTC-6 Pierre-Luc Dallaire-= Demers=20 > wrote: > >> SQIsign is blockchain friendly but also very new, I would recommend=20 >> adding a hash-based backup key in case an attack on SQIsign is found in = the=20 >> future (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 = bit=20 >> to specify the SQIsign branch. >> The hash-based method could be Sphincs+, which is standardized by NIST= =20 >> but requires adding extra code, or Lamport, which is not standardized bu= t=20 >> 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 wrot= e: >> >>> The motivation for this BIP is to provide a concrete proposal for addin= g=20 >>> quantum resistance to Bitcoin. We will need to pick a signature algorit= hm,=20 >>> implement it, and have it ready in event of quantum emergency. There wi= ll=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 thr= eat,=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 l= ow=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 develo= pers=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=20 >>> validate the approach and hear if I should continue working on it, whet= her=20 >>> serious changes are needed, or if this truly isn't a worthwhile endeavo= r=20 >>> right now. >>> >>> 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/87b4e402-39d8-46b0-8269-4f81fa501627n%40googlegroups.com. ------=_Part_200559_122869671.1718586466160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <p style=3D"box-sizing: border-box; margin-bottom: 16px; margin-top: 0px;">= <font size=3D"2"><font color=3D"#1f2328" face=3D"-apple-system, BlinkMacSys= temFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emo= ji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);">Hi Hunter= Beast,</span></font><br /><br /><font color=3D"#1f2328" face=3D"-apple-sys= tem, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif,= Apple Color Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35,= 40);">I think any post-quantum upgrade signature algorithm upgrade proposa= l would grandly benefit to have</span></font><br /><font color=3D"#1f2328" = face=3D"-apple-system, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, = Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"><span style=3D"caret-= color: rgb(31, 35, 40);">Shor's based practical attacks far more defined in= the Bitcoin context. As soon you start to talk about</span></font><br /><f= ont color=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI, = Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"= ><span style=3D"caret-color: rgb(31, 35, 40);">quantum computers there is n= o such thing as a "quantum computer" though a wide array of architectures</= span></font><br /><font color=3D"#1f2328" face=3D"-apple-system, BlinkMacSy= stemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Em= oji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);">based on= a range of technologies to encode qubits on nanoscale physical properties.= </span></font><br /><br /><font color=3D"#1f2328" face=3D"-apple-system, Bl= inkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple = Color Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);">= This is not certain that any Shor's algorithm variant works smoothly indepe= ndently of the quantum computer</span></font><br /><font color=3D"#1f2328" = face=3D"-apple-system, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, = Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"><span style=3D"caret-= color: rgb(31, 35, 40);">architecture considered (e.g gate frequency, gate = infidelity, cooling energy consumption) and I think it's</span></font><br /= ><font color=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, Segoe U= I, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emo= ji"><span style=3D"caret-color: rgb(31, 35, 40);">an interesting open game-= theory problem if you can concentrate a sufficiant amount of energy before = any</span></font><br /><font color=3D"#1f2328" face=3D"-apple-system, Blink= MacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Col= or Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);">coi= n owner moves them in consequence (e.g seeing a quantum break in the mempoo= l and reacting with a counter-spend).</span></font><br /></font></p><p styl= e=3D"box-sizing: border-box; margin-bottom: 16px; margin-top: 0px;"><font s= ize=3D"2">In my opinion, one of the last time the subject was addressed on = the mailing list, the description of the state of<br />the quantum computer= field was not realistic and get into risk characterization hyperbole talki= ng about<br />"super-exponential rate" (when indeed there is no empirical r= ealization=C2=A0that distinct theoretical advance on<br />quantum capabilit= ies=C2=A0can be combined with each other) [1].</font></p><p style=3D"box-si= zing: border-box; margin-bottom: 16px; margin-top: 0px;"><font size=3D"2"><= font color=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI,= Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji= "><span style=3D"caret-color: rgb(31, 35, 40);">On your proposal, there is = an immediate observation which comes to mind, namely why not using one of t= he algorithm</span></font><br /><font color=3D"#1f2328" face=3D"-apple-syst= em, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, = Apple Color Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, = 40);">(dilthium, sphincs+, falcon) which has been through the 3 rounds of N= IST cryptanalysis. Apart of the signature size,</span></font><br /><font co= lor=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI, Noto S= ans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"><span= style=3D"caret-color: rgb(31, 35, 40);">which sounds to be smaller, in a n= etwork of full-nodes any PQ signature algorithm should have reasonable veri= fication</span></font><br /><font color=3D"#1f2328" face=3D"-apple-system, = BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Appl= e Color Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);= ">performances.</span></font><br /><br /><font color=3D"#1f2328" face=3D"-a= pple-system, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, san= s-serif, Apple Color Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb= (31, 35, 40);">Lastly, there is a practical defensive technique that can be= implemented today by coin owners to protect in face of</span></font><br />= <font color=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI= , Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoj= i"><span style=3D"caret-color: rgb(31, 35, 40);">hyptothetical quantum adve= rsaries. Namely setting spending scripts to request an artificially inflate= d witness stack,</span></font><br /><font color=3D"#1f2328" face=3D"-apple-= system, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-ser= if, Apple Color Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, = 35, 40);">as the cost has to be burden by the spender. I think one can easi= ly do that with OP_DUP and OP_GREATERTHAN and a bit</span></font><br /><fon= t color=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI, No= to Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"><= span style=3D"caret-color: rgb(31, 35, 40);">of stack shuffling. While the = efficiency of this technique is limited by the max consensus size of the sc= ript stack </span></font><br /><font color=3D"#1f2328" face=3D"-apple-syste= m, BlinkMacSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, A= pple Color Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, 4= 0);">(`MAX_STACK_SIZE`) and the max consensus size of stack element (`MAX_S= CRIPT_ELEMENT_SIZE`), this adds an additional</span></font><br /><font colo= r=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, Segoe UI, Noto San= s, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"><span s= tyle=3D"caret-color: rgb(31, 35, 40);">"scarce coins" pre-requirement on th= e quantum adversarise to succeed. Shor's algorithm is only defined under th= e</span></font><br /><font color=3D"#1f2328" face=3D"-apple-system, BlinkMa= cSystemFont, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color= Emoji, Segoe UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);">class= ic ressources of computational complexity, time and space.</span></font><br= /><br /><font color=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont,= Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Sego= e UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);">Best,</span></fon= t><br /><font color=3D"#1f2328" face=3D"-apple-system, BlinkMacSystemFont, = Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe= UI Emoji"><span style=3D"caret-color: rgb(31, 35, 40);">Antoine</span></fo= nt></font></p><p style=3D"box-sizing: border-box; margin-bottom: 16px; care= t-color: rgb(31, 35, 40); color: rgb(31, 35, 40); font-family: -apple-syste= m, BlinkMacSystemFont, "Segoe UI", "Noto Sans", Helveti= ca, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji&= quot;; margin-top: 0px;"><font size=3D"2">[1]=C2=A0<span style=3D"color: rg= ba(0, 0, 0, 0.87); font-family: Roboto, RobotoDraft, Helvetica, Arial, sans= -serif;">https://freicoin.substack.com/p/why-im-against-taproot</span></fon= t></p><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_att= r">Le vendredi 14 juin 2024 =C3=A0 15:30:54 UTC+1, Hunter Beast a =C3=A9cri= t=C2=A0:<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;">Good= points. I like your suggestion for a SPHINCS+, just due to how mature it i= s 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><a href=3D"https://w= eb.archive.org/web/20230711000109if_/http://sphincs.org/data/sphincs+-round= 3-submission-nist.zip" target=3D"_blank" rel=3D"nofollow" data-saferedirect= url=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://web.archive.org/w= eb/20230711000109if_/http://sphincs.org/data/sphincs%2B-round3-submission-n= ist.zip&source=3Dgmail&ust=3D1718672420803000&usg=3DAOvVaw0nB6X= iXloG4nlJyz1fs7g1">https://web.archive.org/web/20230711000109if_/http://sph= incs.org/data/sphincs+-round3-submission-nist.zip</a></div><div><br></div><= div>One way to handle this is to introduce this as a separate address type = than SQIsign. That won't require OP_CAT, and I do want to keep this sof= t fork limited in scope. If SQIsign does become significantly broken, in th= is hopefully far future scenario, I might be supportive of an increase in t= he witness discount.<br><div><br></div><div>Also, I've made some additi= onal changes based on your feedback on X. You can review them here if you s= o wish:</div><div><a href=3D"https://github.com/cryptoquick/bips/pull/5/fil= es?short_path=3D917a32a#diff-917a32a71b69bf62d7c85dfb13d520a0340a30a2889b01= 5b82d36411ed45e754" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl= =3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://github.com/cryptoqui= ck/bips/pull/5/files?short_path%3D917a32a%23diff-917a32a71b69bf62d7c85dfb13= d520a0340a30a2889b015b82d36411ed45e754&source=3Dgmail&ust=3D1718672= 420803000&usg=3DAOvVaw0rH-d98RyQJEXu3JfZVxDx">https://github.com/crypto= quick/bips/pull/5/files?short_path=3D917a32a#diff-917a32a71b69bf62d7c85dfb1= 3d520a0340a30a2889b015b82d36411ed45e754</a><br><br></div></div><div class= =3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Friday, June 14,= 2024 at 8:15:29=E2=80=AFAM UTC-6 Pierre-Luc Dallaire-Demers wrote:<br></di= v><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 friendl= y but also very new, I would recommend adding a hash-based backup key in ca= se 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/975.pdf= " rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.go= ogle.com/url?hl=3Dfr&q=3Dhttps://eprint.iacr.org/2022/975.pdf&sourc= e=3Dgmail&ust=3D1718672420803000&usg=3DAOvVaw2nNgEbuvK6PXyk-f8QIKqY= ">https://eprint.iacr.org/2022/975.pdf</a>).<div>Backup keys can be added i= n the form of a Merkle tree where one branch would contain the SQIsign publ= ic 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 branch.<= /div><div>The hash-based method could be Sphincs+, which is standardized by= NIST but requires adding extra code, or Lamport, which is not standardized= 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 1= 2:07:16=E2=80=AFp.m. UTC-4 Hunter Beast 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">The motivation for this BIP is to provide a conc= rete proposal for adding quantum resistance to Bitcoin. We will need to pic= k a signature algorithm, implement it, and have it ready in event of quantu= m emergency. There will be time to adopt it. Importantly, this first step i= s a more substantive answer to those with concerns beyond, "quantum co= mputers may pose a threat, but we likely don't have to worry about that= for a long time". Bitcoin development and activation is slow, so it&#= 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 "QuBit" s= oft fork. The BIP is intended to propose concrete solutions, even if they&#= 39;re early and incomplete, so that Bitcoin developers are aware of the exi= stence of these solutions and their potential.<br><br>This is just a rough = draft and not the finished BIP. I'd like to validate the approach and h= ear if I should continue working on it, whether serious changes are needed,= or if this truly isn'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" target= =3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&= q=3Dhttps://github.com/cryptoquick/bips/blob/p2qrh/bip-p2qrh.mediawiki&= source=3Dgmail&ust=3D1718672420803000&usg=3DAOvVaw1n5w6CUt_3Db-syW3= sv0NB">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></di= v></blockquote></div></blockquote></div></blockquote></div> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" 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/87b4e402-39d8-46b0-8269-4f81fa501627n%40googlegroups.= com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg= id/bitcoindev/87b4e402-39d8-46b0-8269-4f81fa501627n%40googlegroups.com</a>.= <br /> ------=_Part_200559_122869671.1718586466160-- ------=_Part_200558_411727636.1718586466160--