public inbox for
 help / color / mirror / Atom feed
From: Andrew Poelstra <>
To: Matthew Zipkin <>
Cc: Ethan Heilman <>,
	Bitcoin Development Mailing List <>
Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)
Date: Tue, 30 Apr 2024 14:21:40 +0000	[thread overview]
Message-ID: <ZjD-dMMGxoGNgzIg@camus> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

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

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
To view this discussion on the web visit

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2024-04-30 14:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29  0:30 [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed) Ethan Heilman
2024-04-30 12:32 ` Matthew Zipkin
2024-04-30 13:25   ` Ethan Heilman
2024-04-30 14:21   ` Andrew Poelstra [this message]
2024-04-30 20:43     ` Ethan Heilman
2024-05-01  3:46       ` Antoine Riard
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZjD-dMMGxoGNgzIg@camus \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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