Delivery-date: Tue, 30 Apr 2024 14:18:42 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) client-ip=2a00:1450:4864:20::630;
MIME-Version: 1.0
References: <CAEM=y+XyW8wNOekw13C5jDMzQ-dOJpQrBC+qR8-uDot25tM=XA@mail.gmail.com>
 <CA+x5asTOTai_4yNGEgtKEqAchuWJ0jGDEgMqHFYDwactPnrgyw@mail.gmail.com> <ZjD-dMMGxoGNgzIg@camus>
In-Reply-To: <ZjD-dMMGxoGNgzIg@camus>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Tue, 30 Apr 2024 16:43:51 -0400
Message-ID: <CAEM=y+UnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw@mail.gmail.com>
Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport
 Signatures (no changes needed)
To: Andrew Poelstra <apoelstra@wpsoftware.net>
Cc: Matthew Zipkin <pinheadmz@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000a9e3da0617566f3c"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--000000000000a9e3da0617566f3c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One could redesign this scheme to minimize the number of opcodes.

Back of the napkin scheme follows:

Alice, rather than Lamport signing the length of each ECDSA signature,
instead Lamport (or WOTS) signs a vector of the positions of the low-length
ECDSA signatures (low length here means length=3D58 rather than length=3D59=
).
Then the redeem script would only check the length of those particular
signatures and could drop the other other public keys. This saves
significantly on the number of opcodes because we only need to check the
Lamport signature on the vector, no one each signature length and we can
drop unused checked signatures without evaluating them.

Alice's advantage over the attacker is that she gets to fix the positions
of the low length ECDSA signatures after she generates them. This means if
the total number of signatures is N and the number of low length signatures
is M, her advantage over the attacker is (N choose M). For instance if
N=3DM=3D10, to generate 10 59-length signatures, Alice needs to perform
2^(8*10) work. This is because we assume the probability of generating a
58-byte ECDSA signature is 1/256 (1/2^8). However if N=3D40, M=3D10 she onl=
y
needs to perform 2^(8*10)/(40 choose 10) work.

If we assume that we want 80 bits of security, this means we need M=3D10 lo=
w
length ECDCSA signatures (2^(8*10)). The next parameter is how cheap we
want this to be for Alice to compute, we can boost Alice's signing time by
increasing N and remove log2(N choose 10) from the work she needs to
compute the signature. If we want to ensure Alice has to do no more than
2^32 work to sign, then we need N=3D46 or 46 ecdsa signatures.

On Tue, Apr 30, 2024 at 10:21=E2=80=AFAM Andrew Poelstra <apoelstra@wpsoftw=
are.net>
wrote:

> On Tue, Apr 30, 2024 at 08:32:42AM -0400, Matthew Zipkin wrote:
> > > if an attacker managed to grind a 23-byte r-value at a cost of 2^72
> > computations, it would provide the attacker some advantage.
> >
> > If we are assuming discrete log is still hard, why do we need Lamport
> > signatures at all? In a post-quantum world, finding k such that r is 21
> > bytes or less is efficient for the attacker.
> >
>
> Aside from Ethan's point that a variant of this technique is still
> secure in the case that discrete log is totally broken (or even
> partially broken...all we need is that _somebody_ is able to find the
> discrete log of the x=3D1 point and for them to publish this).
>
> Another reason this is useful is that if you have a Lamport signature on
> the stack which is composed of SIZE values, all of which are small
> enough to be manipulated with the numeric script opcodes, then you can
> do covenants in Script.
>
> (Sadly(?), I think none of this works in the context of the 201-opcode
> limit...and absent BitVM challenge-response tricks it's unlikely you can
> do much in the context of the 4MWu block size limit..), but IMO it's a
> pretty big deal that size limits are now the only reason that Bitcoin
> doesn't have covenants.)
>
> --
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web:   https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
>     -Justin Lewis-Webster
>
>

--=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/CAEM%3Dy%2BUnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw%40mail.g=
mail.com.

--000000000000a9e3da0617566f3c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One could redesign this scheme to minimize the number of o=
pcodes.<br><br>Back of the napkin scheme follows:<br><br>Alice, rather than=
 Lamport signing the length of each ECDSA signature, instead Lamport (or WO=
TS) signs a vector of the positions of the low-length ECDSA signatures (low=
 length here means length=3D58 rather than length=3D59). Then the redeem sc=
ript would only check the length of those particular signatures and could d=
rop the other other public keys. This saves significantly on the number of =
opcodes because we only need to check the Lamport signature on the vector, =
no one each signature length and we can drop unused checked signatures with=
out evaluating them.<br><br>Alice&#39;s advantage over the attacker is that=
 she gets to fix the positions of the low length ECDSA signatures after she=
 generates them. This means if the total number of signatures is N and the =
number of low length signatures is M, her advantage over the attacker is (N=
 choose M). For instance if N=3DM=3D10, to generate 10 59-length signatures=
, Alice=C2=A0needs to perform 2^(8*10) work. This is because we assume the =
probability of generating a 58-byte ECDSA signature is 1/256 (1/2^8). Howev=
er if N=3D40, M=3D10 she only needs to perform 2^(8*10)/(40 choose 10) work=
.<br><br>If we assume that we want 80 bits of security, this means we need =
M=3D10 low length ECDCSA signatures (2^(8*10)). The next parameter is how c=
heap we want this to be for Alice to compute, we can boost Alice&#39;s sign=
ing time by increasing N and remove log2(N choose 10) from the work she nee=
ds to compute the signature. If we want to ensure Alice has to do no more t=
han 2^32 work to sign, then we need=C2=A0N=3D46 or 46 ecdsa signatures.<br>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Tue, Apr 30, 2024 at 10:21=E2=80=AFAM Andrew Poelstra &lt;<a href=3D"mai=
lto:apoelstra@wpsoftware.net">apoelstra@wpsoftware.net</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Apr 30, 2024 =
at 08:32:42AM -0400, Matthew Zipkin wrote:<br>
&gt; &gt; if an attacker managed to grind a 23-byte r-value at a cost of 2^=
72<br>
&gt; computations, it would provide the attacker some advantage.<br>
&gt; <br>
&gt; If we are assuming discrete log is still hard, why do we need Lamport<=
br>
&gt; signatures at all? In a post-quantum world, finding k such that r is 2=
1<br>
&gt; bytes or less is efficient for the attacker.<br>
&gt;<br>
<br>
Aside from Ethan&#39;s point that a variant of this technique is still<br>
secure in the case that discrete log is totally broken (or even<br>
partially broken...all we need is that _somebody_ is able to find the<br>
discrete log of the x=3D1 point and for them to publish this).<br>
<br>
Another reason this is useful is that if you have a Lamport signature on<br=
>
the stack which is composed of SIZE values, all of which are small<br>
enough to be manipulated with the numeric script opcodes, then you can<br>
do covenants in Script.<br>
<br>
(Sadly(?), I think none of this works in the context of the 201-opcode<br>
limit...and absent BitVM challenge-response tricks it&#39;s unlikely you ca=
n<br>
do much in the context of the 4MWu block size limit..), but IMO it&#39;s a<=
br>
pretty big deal that size limits are now the only reason that Bitcoin<br>
doesn&#39;t have covenants.)<br>
<br>
-- <br>
Andrew Poelstra<br>
Director, Blockstream Research<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer" ta=
rget=3D"_blank">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer" target=3D"_blank">https://www.wpsoftware.net/andrew</a><br>
<br>
The sun is always shining in space<br>
=C2=A0 =C2=A0 -Justin Lewis-Webster<br>
<br>
</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/CAEM%3Dy%2BUnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGf=
jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.=
google.com/d/msgid/bitcoindev/CAEM%3Dy%2BUnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6=
_WTWFYGfjw%40mail.gmail.com</a>.<br />

--000000000000a9e3da0617566f3c--