From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)
Date: Tue, 30 Apr 2024 20:46:07 -0700 (PDT) [thread overview]
Message-ID: <2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n@googlegroups.com> (raw)
In-Reply-To: <CAEM=y+UnxB2vKQpJAa-z-qGZQfpR1ZeW3UyuFFZ6_WTWFYGfjw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6527 bytes --]
Hi Ethan,
From my understanding, you're proposing to emulate Lamport signature
verification / generation
scheme by leveraging the implicit signature digest of the OP_CHECKSIG
operation, which has been
a valid Bitcoin Script opcode since genesis block. Signature digests is a
commitment to a bitcoin
transaction fields, and this is verified by the interpreter both for ECDSA
and Schnorr schemes.
Here you're proposing to use the ECDSA's `k` nonce as a fixed public value
by committing the
ECDSA-signature length as 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) = y for
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
attacks or invalid curve
domain parameters, 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
transaction-relay network,
there is one fundamental security property of Lamport signature to be aware
off, mainly the one-time
usage. So this is very unclear if as soon you're broadcasting the
transaction, miners coalition could
withhold the transaction inclusion to trigger the initial signer to reveal
more a lot of pre-committed
fixed-nonce 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 of 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 with 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 literature. 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 this post is if we have already
hash-chain-based covenant
"today" in Bitcoin. If by fixing the integer `z` of the s-value of ECDSA
signature in redeem script, and
computing backward the chain of chids redeem scripts to avoid hash-chain
dependencies. This is unclear
what would be the security guarantees and average btc units cost for
scriptSig / witness under current block
size limit of 4MWU.
Best,
Antoine
Le mardi 30 avril 2024 à 22:18:36 UTC+1, Ethan Heilman a écrit :
> 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=58 rather than length=59).
> 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=M=10, 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=40, M=10 she only
> 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=10 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 Alice has to do no more than
> 2^32 work to sign, then we need N=46 or 46 ecdsa signatures.
>
> On Tue, Apr 30, 2024 at 10:21 AM Andrew Poelstra <apoe...@wpsoftware•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=1 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
>>
>>
--
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 email 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.
[-- Attachment #1.2: Type: text/html, Size: 8140 bytes --]
next prev parent reply other threads:[~2024-05-01 8:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 0:30 Ethan Heilman
2024-04-30 12:32 ` Matthew Zipkin
2024-04-30 13:25 ` Ethan Heilman
2024-04-30 14:21 ` Andrew Poelstra
2024-04-30 20:43 ` Ethan Heilman
2024-05-01 3:46 ` Antoine Riard [this message]
2024-05-01 20:02 ` Ethan Heilman
2024-05-06 7:39 ` David A. Harding
2024-05-06 16:48 ` Andrew Poelstra
2024-05-06 18:56 ` David A. Harding
2024-05-06 19:06 ` Andrew Poelstra
2024-05-07 0:55 ` Antoine Riard
2024-05-07 16:05 ` Ethan Heilman
2024-05-07 4:11 ` David A. Harding
2024-05-07 14:34 ` Andrew Poelstra
2024-05-09 0:31 ` Ben Carman
2024-05-09 12:46 ` Andrew Poelstra
2024-05-11 2:53 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2775e9e8-4f1a-4f03-a8f0-4a4c2f6e93a9n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox