Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2F667C000E for ; Fri, 9 Jul 2021 22:53:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1576F606C6 for ; Fri, 9 Jul 2021 22:53:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvbKEDrUorTa for ; Fri, 9 Jul 2021 22:53:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp3.osuosl.org (Postfix) with ESMTPS id 48F7D606A5 for ; Fri, 9 Jul 2021 22:53:10 +0000 (UTC) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 169Mr8Af005146 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 9 Jul 2021 18:53:08 -0400 Received: by mail-io1-f43.google.com with SMTP id l18so9222355iow.4 for ; Fri, 09 Jul 2021 15:53:08 -0700 (PDT) X-Gm-Message-State: AOAM530R37XGJHLp+tQjvSNNbj+dm6CNIDIp0B9oh+UEkEVELsmN7t5e Xd4YfEDO/Y/XELl1+aFB5nPX8dyddta8xKbU6LI= X-Google-Smtp-Source: ABdhPJxDAMizrxSolAyDMWwR8KZNXuO/x/wzuVlkRJa/ANoC70Ou21XENuT8NnK/a7NiYebYpB9Fd2tH5DFVshocQi0= X-Received: by 2002:a6b:7e0a:: with SMTP id i10mr5909647iom.92.1625871187921; Fri, 09 Jul 2021 15:53:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Fri, 9 Jul 2021 15:52:56 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Ethan Heilman Content-Type: multipart/alternative; boundary="0000000000009b50e105c6b8a2e8" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values] X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 22:53:13 -0000 --0000000000009b50e105c6b8a2e8 Content-Type: text/plain; charset="UTF-8" I thought about this, but at the time of writing I couldn't come up with something I thought was substantially better. I spent a few more cycles thinking on it -- you can definitely do better. It's not clear how much better Winternitz might be, or if it would be secure in this context? Here's some exploration... maybe you can do something like: || IF SWAP HASH SWAP ELSE HASH FROMALTSTACK <2**n> TOALTSTACK ADD ENDIF CAT you can process this (assume HASH160) into chunks of 26 bits, cat them all together, and then stash that hash. You would need 6 gadgets, and then 1 overflow + 4 bare hashes for the final key hash (e.g. your tree looks like) H(H(26x20) || H(26x20)...H(bit)|| H(bit) || H(bit) || H(bit)). It doesn't make sense to have a "nice" merkle tree, just fit in as much data as possible per call (520 bytes). If OP_SHASTREAM, this is even better since you can ignore structuring... This would bring your cost down by about 20 bytes per bit, for 160 bits, so around a savings of 3200 bytes... not bad! 1/3 cheaper. Script is about 15x160 = 2400 and change, witness is 43x160 = 6880 If you were to convert to 3-ary, you could cut this down to 101 gates with a script like: witnesses: <0> <1> <2> script: HASH SWAP IFDUP NOTIF # 0 passed in (0) SWAP CAT ELSE <3**n> TOALT 1SUB IF # 2 passed in (+1) FROMALT # do nothing ELSE # 1 passed in (T) SWAP # Swaps H(xT) to back FROMALT NEGATE # negate END FROMALT ADD TOALT # add to accumulator ENDIF CAT you would end up having to publish ~64x101 data in the witness, so only 6464 total (and about 24x101 = 2424 and change for the script) Making the script smaller also means that choice of hash160/sha256 doesn't change script size much, just witness. And the witnesses are free to provide their own preimages, so it would be OK to use something > 20 bytes, < 32 for more variable security/length tradeoff. At the cost of marginally bigger script (by about 6x101 bytes), you can save 20x101 off the witness stack by making each key H(H(xT) || H(x0)) || H(x1). 43x101 + 30x101 = 7373 + change for the final grouping. witnesses: <0> <1> <2> script: HASH SWAP IFDUP NOTIF # 0 passed in (0) ROT SWAP CAT HASH ELSE <3**n> TOALT 1SUB IF # 2 passed in (+1) FROMALT # do nothing ELSE # 1 passed in (T) TOALTSTACK CAT HASH FROMALTSTACK SWAP # Swaps H(xT) to back FROMALT NEGATE # negate END FROMALT ADD TOALT # add to accumulator ENDIF CAT -- @JeremyRubin On Fri, Jul 9, 2021 at 12:03 PM Ethan Heilman wrote: > >Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple > kilobytes)... blocksize increase *cough* > > Couldn't you significantly compress the signatures by using either > Winternitz OTS or by using OP_CAT to build a merkle tree so that the > full signature can be derived during script execution from a much > shorter set of seed values? > > On Thu, Jul 8, 2021 at 4:12 AM ZmnSCPxj via bitcoin-dev > wrote: > > > > > > Good morning Jeremy, > > > > Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple > kilobytes)... blocksize increase *cough* > > > > Since a quantum computer can derive the EC privkey from the EC pubkey > and this scheme is resistant to that, I think you can use a single > well-known EC privkey, you just need a unique Lamport keypair for each UTXO > (uniqueness being mandatory due to Lamport requiring preimage revelation). > > > > Regards, > > ZmnSCPxj > > > > > > > Dear Bitcoin Devs, > > > > > > As mentioned previously, OP_CAT (or similar operation) can be used to > make Bitcoin "quantum safe" by signing an EC signature. This should work in > both Segwit V0 and Tapscript, although you have to use HASH160 for it to > fit in Segwit V0. > > > > > > See [my blog](https://rubin.io/blog/2021/07/06/quantum-bitcoin/) for > the specific construction, reproduced below. > > > > > > Yet another entry to the "OP_CAT can do that too" list. > > > > > > Best, > > > > > > Jeremy > > > ----- > > > > > > I recently published [a blog > > > post](https://rubin.io/blog/2021/07/02/signing-5-bytes/) about > signing up to a > > > 5 byte value using Bitcoin script arithmetic and Lamport signatures. > > > > > > By itself, this is neat, but a little limited. What if we could sign > longer > > > messages? If we can sign up to 20 bytes, we could sign a HASH160 > digest which > > > is most likely quantum safe... > > > > > > What would it mean if we signed the HASH160 digest of a signature? > What the > > > what? Why would we do that? > > > > > > Well, as it turns out, even if a quantum computer were able to crack > ECDSA, it > > > would yield revealing the private key but not the ability to malleate > the > > > content of what was actually signed. I asked my good friend and > cryptographer > > > [Madars Virza](https://madars.org/) if my intuition was correct, and > he > > > confirmed that it should be sufficient, but it's definitely worth > closer > > > analysis before relying on this. While the ECDSA signature can be > malleated to a > > > different, negative form, if the signature is otherwise made > immalleable there > > > should only be one value the commitment can be opened to. > > > > > > If we required the ECDSA signature be signed with a quantum proof > signature > > > algorithm, then we'd have a quantum proof Bitcoin! And the 5 byte > signing scheme > > > we discussed previously is a Lamport signature, which is quantum > secure. > > > Unfortunately, we need at least 20 contiguous bytes... so we need some > sort of > > > OP\_CAT like operation. > > > > > > OP\_CAT can't be directly soft forked to Segwit v0 because it modifies > the > > > stack, so instead we'll (for simplicity) also show how to use a new > opcode that > > > uses verify semantics, OP\_SUBSTRINGEQUALVERIFY that checks a splice > of a string > > > for equality. > > > > > > ``` > > > ... FOR j in 0..=5 > > > <0> > > > ... FOR i in 0..=31 > > > SWAP hash160 DUP EQUAL IF DROP <2**i> ADD ELSE > EQUALVERIFY ENDIF > > > ... END FOR > > > TOALTSTACK > > > ... END FOR > > > > > > DUP HASH160 > > > > > > ... IF CAT AVAILABLE > > > FROMALTSTACK > > > ... FOR j in 0..=5 > > > FROMALTSTACK > > > CAT > > > ... END FOR > > > EQUALVERIFY > > > ... ELSE SUBSTRINGEQUALVERIFY AVAILABLE > > > ... FOR j in 0..=5 > > > FROMALTSTACK <0+j*4> <4+j*4> SUBSTRINGEQUALVERIFY DROP DROP > DROP > > > ... END FOR > > > DROP > > > ... END IF > > > > > > CHECKSIG > > > ``` > > > > > > That's a long script... but will it fit? We need to verify 20 bytes of > message > > > each bit takes around 10 bytes script, an average of 3.375 bytes per > number > > > (counting pushes), and two 21 bytes keys = 55.375 bytes of program > space and 21 > > > bytes of witness element per bit. > > > > > > It fits! `20*8*55.375 = 8860`, which leaves 1140 bytes less than the > limit for > > > the rest of the logic, which is plenty (around 15-40 bytes required > for the rest > > > of the logic, leaving 1100 free for custom signature checking). The > stack size > > > is 160 elements for the hash gadget, 3360 bytes. > > > > > > This can probably be made a bit more efficient by expanding to a > ternary > > > representation. > > > > > > ``` > > > SWAP hash160 DUP EQUAL IF DROP ELSE <3**i> SWAP > DUP EQUAL IF DROP SUB ELSE EQUALVERIFY ADD ENDIF > ENDIF > > > ``` > > > > > > This should bring it up to roughly 85 bytes per trit, and there should > be 101 > > > trits (`log(2**160)/log(3) == 100.94`), so about 8560 bytes... a bit > cheaper! > > > But the witness stack is "only" `2121` bytes... > > > > > > As a homework exercise, maybe someone can prove the optimal choice of > radix for > > > this protocol... My guess is that base 4 is optimal! > > > > > > ## Taproot? > > > > > > What about Taproot? As far as I'm aware the commitment scheme (`Q = pG > + hash(pG > > > || m)G`) can be securely opened to m even with a quantum computer > (finding `q` > > > such that `qG = Q` might be trivial, but suppose key path was > disabled, then > > > finding m and p such that the taproot equation holds should be > difficult because > > > of the hash, but I'd need to certify that claim better). Therefore > this > > > script can nest inside of a Tapscript path -- Tapscript also does not > impose a > > > length limit, 32 byte hashes could be used as well. > > > > > > Further, to make keys reusable, there could be many Lamport keys > comitted inside > > > a taproot tree so that an address could be used for thousands of times > before > > > expiring. This could be used as a measure to protect accidental use > rather than > > > to support it. > > > > > > Lastly, Schnorr actually has a stronger non-malleability property than > ECDSA, > > > the signatures will be binding to the approved transaction and once > Lamport > > > signed, even a quantum computer could not steal the funds. > > > > > > -- > > > @JeremyRubin > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000009b50e105c6b8a2e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought about this, but= at the time of writing I couldn't come up with something I thought was= substantially better. I spent a few more cycles thinking on it -- you can = definitely do better. It's not clear how much better Winternitz might b= e, or if it would be secure in this context? Here's some exploration...=

maybe you can do something like:

<x0> <H(x1)> <= dir in {0,1}> || IF SWAP HASH SWAP ELSE HASH FROMALTSTACK <2**n> T= OALTSTACK ADD ENDIF CAT

you can process this (assume HASH160) into ch= unks of 26 bits, cat them all together, and then stash that hash. You would= need 6 gadgets, and then 1 overflow=C2=A0+ 4 bare hashes for the final key= hash (e.g. your tree looks like) H(H(26x20) || H(26x20)...H(bit)|| H(bit) = || H(bit) || H(bit)). It doesn't make sense to have a "nice" = merkle tree, just fit in as much data=C2=A0as possible per call (520 bytes)= . If OP_SHASTREAM, this is even better since you can ignore structuring...<= /div>

This would bring your cost down by about 20 bytes per bit, for 160 bi= ts, so around a savings of 3200 bytes... not bad! 1/3 cheaper.

Script= is about 15x160 =3D 2400 and change, witness is 43x160 =3D 6880

If y= ou were to convert to 3-ary, you could cut this down to 101 gates with a sc= ript like:

witnesses:
<H(xT)= > <H(x1)> =C2=A0=C2=A0<0> <x0>
<H(x0) || H(x1)> <= ;1> <xT>=C2=A0<= /div>
<H(= xT) || H(x0)> =C2=A0<2> <x1>

script:
HASH= SWAP
IFDUP
NOTIF =C2=A0 =C2=A0# 0 passed in (0)
=C2=A0 =C2=A0 SWAP CAT
<= div class=3D"gmail_default">ELSE
=C2= =A0 =C2=A0 <3**n> TOALT=C2=A0
=C2= =A0 =C2=A0 1SUB
=C2=A0 =C2=A0 I= F # 2 passed in (+1)
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 FROMALT # do nothing
= =C2=A0 =C2=A0 ELSE # 1 passed in (T)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SWAP= # Swaps H(xT) to back
=C2=A0 =C2=A0 =C2=A0 =C2=A0 FROMALT NEGATE # negate
=C2=A0 =C2=A0 END
=
=C2=A0 =C2=A0= FROMALT ADD TOALT # add to accumulator=C2=A0
ENDIF
CAT


you would end up having to publish ~64x101 data in the witn= ess, so only 6464 total (and about 24x101 =3D 2424 and change for the scrip= t)

Making the script smaller also means that choice of hash160/sha256= doesn't change script size much, just witness. And the witnesses are f= ree to provide their own preimages, so it would be OK to use something >= 20 bytes, < 32 for more variable security/length tradeoff.


At the cost of marginally bigger scrip= t (by about 6x101 bytes), you can save 20x101 off the witness stack by maki= ng each key H(H(xT) || H(x0)) || H(x1). 43x101=C2=A0+ 30x101 =3D 7373=C2=A0= + change for the final grouping.

=
witness= es:
<H(xT)> <H(x1)> =C2=A0=C2=A0<0> <x0><= /div>
<H(x0)> <H(x1)> <1> <xT>=C2=A0
<H(H(xT) || H(x0))> =C2= =A0<2> <x1>

script:
HASH SWAP
IFDUP
NOTIF =C2=A0 =C2=A0# = 0 passed in (0)
=C2=A0 =C2=A0 ROT SWAP CAT HASH
E= LSE
=C2=A0 =C2=A0 <3**n> TOALT= =C2=A0
=C2=A0 =C2=A0 1SUB
=C2=A0 =C2=A0 IF # 2 passed in (+1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 FROMALT # do nothing
<= div class=3D"gmail_default">=C2=A0 =C2=A0 ELSE # 1 passed in (T)
<= div class=3D"gmail_default">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TOALTSTACK CAT HASH FROMALTSTACK SWAP # Swaps H(xT) to back
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 FROMALT NEGATE # negate
=C2= =A0 =C2=A0 END
=C2=A0 =C2=A0 FROMALT = ADD TOALT # add to accumulator=C2=A0
ENDI= F
CAT


=

On Fri, Jul 9, 2021 at 12:03= PM Ethan Heilman <eth3rs@gmail.com<= /a>> wrote:
>Yes, quite neat indeed, too ba= d Lamport signatures are so huge (a couple kilobytes)... blocksize increase= *cough*

Couldn't you significantly compress the signatures by using either
Winternitz OTS or by using OP_CAT to build a merkle tree so that the
full signature can be derived during script execution from a much
shorter set of seed values?

On Thu, Jul 8, 2021 at 4:12 AM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> Good morning Jeremy,
>
> Yes, quite neat indeed, too bad Lamport signatures are so huge (a coup= le kilobytes)... blocksize increase *cough*
>
> Since a quantum computer can derive the EC privkey from the EC pubkey = and this scheme is resistant to that, I think you can use a single well-kno= wn EC privkey, you just need a unique Lamport keypair for each UTXO (unique= ness being mandatory due to Lamport requiring preimage revelation).
>
> Regards,
> ZmnSCPxj
>
>
> > Dear Bitcoin Devs,
> >
> > As mentioned previously, OP_CAT (or similar operation) can be use= d to make Bitcoin "quantum safe" by signing an EC signature. This= should work in both Segwit V0 and Tapscript, although you have to use HASH= 160 for it to fit in Segwit V0.
> >
> > See [my blog](https://rubin.io/blog/2021/= 07/06/quantum-bitcoin/) for the specific construction, reproduced below= .
> >
> > Yet another entry to the "OP_CAT can do that too" list.=
> >
> > Best,
> >
> > Jeremy
> > -----
> >
> > I recently published [a blog
> > post](https://rubin.io/blog/2021/07/02/si= gning-5-bytes/) about signing up to a
> > 5 byte value using Bitcoin script arithmetic and Lamport signatur= es.
> >
> > By itself, this is neat, but a little limited. What if we could s= ign longer
> > messages? If we can sign up to 20 bytes, we could sign a HASH160 = digest which
> > is most likely quantum safe...
> >
> > What would it mean if we signed the HASH160 digest of a signature= ? What the
> > what? Why would we do that?
> >
> > Well, as it turns out, even if a quantum computer were able to cr= ack ECDSA, it
> > would yield revealing the private key but not the ability to mall= eate the
> > content of what was actually signed.=C2=A0 I asked my good friend= and cryptographer
> > [Madars Virza](https://madars.org/) if my intuition was correct, an= d he
> > confirmed that it should be sufficient, but it's definitely w= orth closer
> > analysis before relying on this. While the ECDSA signature can be= malleated to a
> > different, negative form, if the signature is otherwise made imma= lleable there
> > should only be one value the commitment can be opened to.
> >
> > If we required the ECDSA signature be signed with a quantum proof= signature
> > algorithm, then we'd have a quantum proof Bitcoin! And the 5 = byte signing scheme
> > we discussed previously is a Lamport signature, which is quantum = secure.
> > Unfortunately, we need at least 20 contiguous bytes... so we need= some sort of
> > OP\_CAT like operation.
> >
> > OP\_CAT can't be directly soft forked to Segwit v0 because it= modifies the
> > stack, so instead we'll (for simplicity) also show how to use= a new opcode that
> > uses verify semantics, OP\_SUBSTRINGEQUALVERIFY that checks a spl= ice of a string
> > for equality.
> >
> > ```
> > ... FOR j in 0..=3D5
> >=C2=A0 =C2=A0 =C2=A0<0>
> >=C2=A0 =C2=A0 =C2=A0... FOR i in 0..=3D31
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SWAP hash160 DUP <H(K_j_i_1)&= gt; EQUAL IF DROP <2**i> ADD ELSE <H(K_j_i_0)> EQUALVERIFY ENDI= F
> >=C2=A0 =C2=A0 =C2=A0... END FOR
> >=C2=A0 =C2=A0 =C2=A0TOALTSTACK
> > ... END FOR
> >
> > DUP HASH160
> >
> > ... IF CAT AVAILABLE
> >=C2=A0 =C2=A0 =C2=A0FROMALTSTACK
> >=C2=A0 =C2=A0 =C2=A0... FOR j in 0..=3D5
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FROMALTSTACK
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CAT
> >=C2=A0 =C2=A0 =C2=A0... END FOR
> >=C2=A0 =C2=A0 =C2=A0EQUALVERIFY
> > ... ELSE SUBSTRINGEQUALVERIFY AVAILABLE
> >=C2=A0 =C2=A0 =C2=A0... FOR j in 0..=3D5
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FROMALTSTACK <0+j*4> <4= +j*4> SUBSTRINGEQUALVERIFY DROP DROP DROP
> >=C2=A0 =C2=A0 =C2=A0...=C2=A0 END FOR
> >=C2=A0 =C2=A0 =C2=A0DROP
> > ... END IF
> >
> > <pk> CHECKSIG
> > ```
> >
> > That's a long script... but will it fit? We need to verify 20= bytes of message
> > each bit takes around 10 bytes script, an average of 3.375 bytes = per number
> > (counting pushes), and two 21 bytes keys =3D 55.375 bytes of prog= ram space and 21
> > bytes of witness element per bit.
> >
> > It fits! `20*8*55.375 =3D 8860`, which leaves 1140 bytes less tha= n the limit for
> > the rest of the logic, which is plenty (around 15-40 bytes requir= ed for the rest
> > of the logic, leaving 1100 free for custom signature checking). T= he stack size
> > is 160 elements for the hash gadget, 3360 bytes.
> >
> > This can probably be made a bit more efficient by expanding to a = ternary
> > representation.
> >
> > ```
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SWAP hash160 DUP <H(K_j_i_0)&= gt; EQUAL=C2=A0 IF DROP=C2=A0 ELSE <3**i> SWAP DUP <H(K_j_i_T)>= EQUAL IF DROP SUB ELSE <H(K_j_i_1)> EQUALVERIFY ADD=C2=A0 ENDIF ENDI= F
> > ```
> >
> > This should bring it up to roughly 85 bytes per trit, and there s= hould be 101
> > trits (`log(2**160)/log(3) =3D=3D 100.94`), so about 8560 bytes..= . a bit cheaper!
> > But the witness stack is "only" `2121` bytes...
> >
> > As a homework exercise, maybe someone can prove the optimal choic= e of radix for
> > this protocol... My guess is that base 4 is optimal!
> >
> > ## Taproot?
> >
> > What about Taproot? As far as I'm aware the commitment scheme= (`Q =3D pG + hash(pG
> > || m)G`) can be securely opened to m even with a quantum computer= (finding `q`
> > such that `qG =3D Q` might be trivial, but suppose key path was d= isabled, then
> > finding m and p such that the taproot equation holds should be di= fficult because
> > of the hash, but I'd need to certify that claim better).=C2= =A0 Therefore this
> > script can nest inside of a Tapscript path -- Tapscript also does= not impose a
> > length limit, 32 byte hashes could be used as well.
> >
> > Further, to make keys reusable, there could be many Lamport keys = comitted inside
> > a taproot tree so that an address could be used for thousands of = times before
> > expiring. This could be used as a measure to protect accidental u= se rather than
> > to support it.
> >
> > Lastly, Schnorr actually has a stronger non-malleability property= than ECDSA,
> > the signatures will be binding to the approved transaction and on= ce Lamport
> > signed, even a quantum computer could not steal the funds.
> >
> > --
> > @JeremyRubin
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
--0000000000009b50e105c6b8a2e8--