From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 01 May 2024 01:57:26 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s25mH-00025b-DY for bitcoindev@gnusha.org; Wed, 01 May 2024 01:57:26 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-de45c577ca9sf808135276.0 for ; Wed, 01 May 2024 01:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1714553839; x=1715158639; 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=aU/UqRa7ZksSi5+gWAYiKFHejGtgAc/vK8qiumL/izQ=; b=D0CL3uzSG8b2yq+7tfBItgWzpU0Ai16OB2hrrsSumwt9fICPvV/W6HAzCfoHyheQg+ QfayQxB/xBaIUZuTaXmdqG4tvZgO2gWAPOpsq1+b53l0l9ns3W1ktvLz1Md6dajCgTQw t/9mG2Yx+lUe4bHAbvVE43xAWrEH51nCFl/+PDAQzRrsGUPX5FrkJBbovS2Kfvc2npYO aARdBRy1AsqB4GJNSP3ufOngHoeWChfhTKEllrYZMjCtWPYtyZ2E3HV2DUiL4TEbAUXF L4O+hZIkUlEAXl3PFxWSPoPRw2NjnR0Qz7WgmTKXQxWKuRhPWJTBIuIHB6wEQFwIkNzp LmtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714553839; x=1715158639; 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=aU/UqRa7ZksSi5+gWAYiKFHejGtgAc/vK8qiumL/izQ=; b=Zm02+D2gF+eSfimNy5HxCEflsWZ3+qUyJ8uTtoROejWrfdjIq9DIdH3dc1ZvPjjG6t u5900PENSDBQPGo0ExS+doc/NOWWlxBtPnKoHioV5AZjmpVIv59kCaseFtp/AZE0XaqH VmYr7YZ9v97jXMCYn4Vv8c2QCouzvT3oH1wY4KCr4wvKLa9sppNm5lO6AEangtV/qWrI 7h+WSwUS+ZHXxVbnbzxumTeMo1EoA2cIrvFlZpelV2HS5ZhE5011GwlOYIM/y4emPDKA rwWFBZVv+WcBIgMj84C71saD4GjW7KvQnKy681Fu748ZsBlzySomYNbgTVeES30r6W9K nXHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714553839; x=1715158639; 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=aU/UqRa7ZksSi5+gWAYiKFHejGtgAc/vK8qiumL/izQ=; b=F1LyVq46nxsvLbJxHCcUpYHT4hOrSB2nQ1cg+CmMw00iAe3lqVmB9JULIXe3zZ4OMj Rxk/nj8WgIGBC20LDhkenCkSKYo++fwhHv/M+4DyRo09f/I2nbuieMcBmdmsjt9iv/Ss 28R+fiCeMJmartx2jsuZXc6EOWzTDNg7paNFsv1CGilUOeCJsAWgxPzZA+XPpYcHbpq+ QHDfrDVF09W2SF8otjmLlF1ogS0lUO+A4AoFn0bFW58HiaadpVlJW3Xo2Q0x8rVh065p ROlzqrlDcPfx+2P8E9jtsmS0JvLIMioz//9HEydiNZNO+uoLHDkzX3rjBX5czFMRYBCK JgyQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVro/Kag9UiWjka9MYAsCRh1Wv18bxf/rYEpn8wmzirxVY9ehPTiiDNWrurLeeSkTqmuXSz4Ml5B5GcqUk/YBs5De8vUIQ= X-Gm-Message-State: AOJu0YybitoiOn6JmZX4Fp5VMAxp2sOfUYmWBsqjef8IK917zd8FMqfu jenMx0PYWoIFm3s7hASIqE9QVFfr2yVi5PLewiJIOsJKoeBHBPrj X-Google-Smtp-Source: AGHT+IFUtSK+sEas0WP5tUsY5cIjrQBmNa/EHY3y6XN+U+GStJBY9v+3ISZnLKXjpyT3KDf12FCxMA== X-Received: by 2002:a5b:b49:0:b0:de5:5869:47d8 with SMTP id b9-20020a5b0b49000000b00de5586947d8mr1512504ybr.9.1714553838792; Wed, 01 May 2024 01:57:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:948:0:b0:de5:9eb1:327d with SMTP id 3f1490d57ef6-de59eb13f8fls128186276.2.-pod-prod-06-us; Wed, 01 May 2024 01:57:17 -0700 (PDT) X-Received: by 2002:a81:8381:0:b0:61b:eea2:de55 with SMTP id t123-20020a818381000000b0061beea2de55mr524918ywf.7.1714553837041; Wed, 01 May 2024 01:57:17 -0700 (PDT) Received: by 2002:a05:690c:39c:b0:61b:e8f5:76d6 with SMTP id 00721157ae682-61dfb025199ms7b3; Tue, 30 Apr 2024 20:46:08 -0700 (PDT) X-Received: by 2002:a05:6902:2b0a:b0:dc6:e884:2342 with SMTP id fi10-20020a0569022b0a00b00dc6e8842342mr571189ybb.5.1714535167561; Tue, 30 Apr 2024 20:46:07 -0700 (PDT) Date: Tue, 30 Apr 2024 20:46:07 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_25720_608833718.1714535167151" X-Original-Sender: antoine.riard@gmail.com 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.5 (/) ------=_Part_25720_608833718.1714535167151 Content-Type: multipart/alternative; boundary="----=_Part_25721_1931232839.1714535167151" ------=_Part_25721_1931232839.1714535167151 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ethan, >From my understanding, you're proposing to emulate Lamport signature=20 verification / generation scheme by leveraging the implicit signature digest of the OP_CHECKSIG=20 operation, which has been a valid Bitcoin Script opcode since genesis block. Signature digests is a= =20 commitment to a bitcoin transaction fields, and this is verified by the interpreter both for ECDSA= =20 and Schnorr schemes. Here you're proposing to use the ECDSA's `k` nonce as a fixed public value= =20 by committing the ECDSA-signature length as a parameter of an OP_SIZE and the cleartext `r,s`= =20 signature itself as the verification parameter of a OP_SHA256, emulating the h(x) =3D y for=20 Lamport signature range of bits, all in a redeem script (i.e P2SH). I don't know if your proposed scheme is secure against message forgery=20 attacks or invalid curve domain parameters, e.g using the point at infinity as your point R, and if= =20 from them you could play tricks with coordinates. On the usage of such emulated Lamport signature scheme in a public=20 transaction-relay network, there is one fundamental security property of Lamport signature to be aware= =20 off, mainly the one-time usage. So this is very unclear if as soon you're broadcasting the=20 transaction, miners coalition could withhold the transaction inclusion to trigger the initial signer to reveal= =20 more a lot of pre-committed fixed-nonce ECDSA signatures. Apart of concerns of this scheme in a blockchain and assuming it's not=20 utterly broken due to message forgery attacks, I'm skeptical on the robustness of the scheme as= =20 the number of on-chain pre-committed signatures is a parameter of the preimage-resistance of the= =20 Lamport signature scheme itself. Sounds a classic time-space tradeoff, by increasing the lot of=20 fixed-nonce signatures we're making it harder to break, even for observers with significant computational=20 ressources. Beyond, 2^64 bit of security doesn't seem a lot in considerations of=20 state-of-the-art collision attacks on hash functions from recent academic literature. And one have to consider= =20 how you can take the short-cut by pre-computing rainbow tables for ECDSA r-value of a given=20 signature size. I think a more interesting open question of this post is if we have already= =20 hash-chain-based covenant "today" in Bitcoin. If by fixing the integer `z` of the s-value of ECDSA=20 signature in redeem script, and computing backward the chain of chids redeem scripts to avoid hash-chain=20 dependencies. This is unclear what would be the security guarantees and average btc units cost for=20 scriptSig / witness under current block size limit of 4MWU. Best, Antoine Le mardi 30 avril 2024 =C3=A0 22:18:36 UTC+1, Ethan Heilman a =C3=A9crit : > 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,=20 > instead Lamport (or WOTS) signs a vector of the positions of the low-leng= th=20 > ECDSA signatures (low length here means length=3D58 rather than length=3D= 59).=20 > Then the redeem script would only check the length of those particular=20 > signatures and could drop the other other public keys. This saves=20 > significantly on the number of opcodes because we only need to check the= =20 > Lamport signature on the vector, no one each signature length and we can= =20 > drop unused checked signatures without evaluating them. > > Alice's advantage over the attacker is that she gets to fix the positions= =20 > of the low length ECDSA signatures after she generates them. This means i= f=20 > the total number of signatures is N and the number of low length signatur= es=20 > is M, her advantage over the attacker is (N choose M). For instance if=20 > N=3DM=3D10, to generate 10 59-length signatures, Alice needs to perform= =20 > 2^(8*10) work. This is because we assume the probability of generating a= =20 > 58-byte ECDSA signature is 1/256 (1/2^8). However if N=3D40, M=3D10 she o= nly=20 > 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 = low=20 > length ECDCSA signatures (2^(8*10)). The next parameter is how cheap we= =20 > want this to be for Alice to compute, we can boost Alice's signing time b= y=20 > increasing N and remove log2(N choose 10) from the work she needs to=20 > compute the signature. If we want to ensure Alice has to do no more than= =20 > 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 =20 > 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. >> >=20 >> > 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 2= 1 >> > 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.) >> >> --=20 >> 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/2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n%40googlegroups.com. ------=_Part_25721_1931232839.1714535167151 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ethan,

From my understanding, you're proposing to e= mulate Lamport signature verification / generation
scheme by leve= raging the implicit signature digest of the OP_CHECKSIG operation, which ha= s been
a valid Bitcoin Script opcode since genesis block. Signatu= re digests is a commitment to a bitcoin
transaction fields, and t= his is verified by the interpreter both for ECDSA and Schnorr schemes.

Here you're proposing to use the ECDSA's `k` nonce a= s a fixed public value by committing the
ECDSA-signature length a= s a parameter of an OP_SIZE and the cleartext `r,s` signature itself as
the verification parameter of a OP_SHA256, emulating the h(x) =3D y = for Lamport signature range of
bits, all in a redeem script (i.e = P2SH).

I don't know if your proposed scheme is s= ecure against message forgery attacks or invalid curve
domain par= ameters, e.g using the point at infinity as your point R, and if from them = you could play
tricks with coordinates.

On the usage of such emulated Lamport signature scheme in a public transa= ction-relay network,
there is one fundamental security property o= f Lamport signature to be aware off, mainly the one-time
usage. S= o this is very unclear if as soon you're broadcasting the transaction, mine= rs coalition could
withhold the transaction inclusion to trigger = the initial signer to reveal more a lot of pre-committed
fixed-no= nce ECDSA signatures.

Apart of concerns of this = scheme in a blockchain and assuming it's not utterly broken due to
message forgery attacks, I'm skeptical on the robustness of the scheme as= the number of on-chain
pre-committed signatures is a parameter o= f the preimage-resistance of the Lamport signature scheme
itself.= Sounds a classic time-space tradeoff, by increasing the lot of fixed-nonce= signatures we're making
it harder to break, even for observers w= ith significant computational ressources.

Beyond= , 2^64 bit of security doesn't seem a lot in considerations of state-of-the= -art collision attacks
on hash functions from recent academic lit= erature. And one have to consider how you can take the
short-cut = by pre-computing rainbow tables for ECDSA r-value of a given signature size= .

I think a more interesting open question of th= is post is if we have already hash-chain-based covenant
"today" i= n Bitcoin. If by fixing the integer `z` of the s-value of ECDSA signature i= n redeem script, and
computing backward the chain of chids redeem= scripts to avoid hash-chain dependencies. This is unclear
what w= ould be the security guarantees and average btc units cost for scriptSig / = witness under current block
size limit of 4MWU.

<= /div>
Best,
Antoine
Le mardi 30 avril 2024 =C3=A0 22:18:36 UTC+1= , Ethan Heilman a =C3=A9crit=C2=A0:
One could redesign this scheme to m= inimize 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-lengt= h ECDSA signatures (low length here means length=3D58 rather than length=3D= 59). Then the redeem script would only check the length of those particular= signatures and could drop the other other public keys. This saves signific= antly on the number of opcodes because we only need to check the Lamport si= gnature on the vector, no one each signature length and we can drop unused = checked signatures without evaluating them.

Alice's advantage ov= er the attacker is that she gets to fix the positions of the low length ECD= SA signatures after she generates them. This means if the total number of s= ignatures 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). However if N=3D40, M=3D10 she only needs to perform 2^(8*= 10)/(40 choose 10) work.

If we assume that we want 80 bits of securi= ty, this means we need M=3D10 low 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 Al= ice has to do no more than 2^32 work to sign, then we need=C2=A0N=3D46 or 4= 6 ecdsa signatures.

On Tue, Apr 30, 2024 at 10:21=E2=80=AFAM Andrew Poel= stra <apoe...@wpsoftware.net<= /a>> wrote:
O= n 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<= br> > signatures at all? In a post-quantum world, finding k such that r is 2= 1
> 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 ca= n
do much in the context of the 4MWu block size limit..), but IMO it's a<= br> 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:=C2=A0 =C2=A0http= s://www.wpsoftware.net/andrew

The sun is always shining in space
=C2=A0 =C2=A0 -Justin Lewis-Webster

--
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/2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n%40googlegroups.com.=
------=_Part_25721_1931232839.1714535167151-- ------=_Part_25720_608833718.1714535167151--