From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: "David A. Harding" <dave@dtrt•org>
Cc: Matthew Zipkin <pinheadmz@gmail•com>,
Ethan Heilman <eth3rs@gmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)
Date: Tue, 7 May 2024 14:34:02 +0000 [thread overview]
Message-ID: <Zjo72iTDYjwwsXW3@camus> (raw)
In-Reply-To: <93b8ed39b0aa3955eb9cb99f9fc5aae9@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]
On Mon, May 06, 2024 at 06:11:48PM -1000, David A. Harding wrote:
> On 2024-05-06 09:06, Andrew Poelstra wrote:
> > You can implement ECDSA. It will just take a *lot* of opcodes.
>
> I'll accept that as a given, but how do you know that a given ECDSA
> signature actually commits to the transaction that contains it if
> OP_CHECKSIG only operates on fixed-size schnorr signatures?
>
You need to connect your Lamport signature to an ECDSA CHECKSIG (in a
pre-Taproot output). So what I'm depending on here is that it's possible
to "copy the signature" from a pre-Taproot spend to a post-Taproot spend
by using Lamport signatures and some anti-equivocation scheme.
In pre-Taproot we confirm that the signature matches the pattern of
OP_SIZE outputs. In post-Taproot we reconstruct the signature and
constrain the transaction, checking that it spends *both* the
pre-Taproot and the post-Taproot output.
> Is this what you're describing: if the controlling signature is a lamport
> signature that commits to an ECDSA signature, it's safe to disclose the
> private key for the ECDSA signature; when you don't have to worry about
> private key disclosure, it's safe to construct a schnorr signature that uses
> the same private key, nonce, and message commitment as the ECDSA signature;
> if that schnorr signature makes OP_CHECKSIG return true, then you know the
> message is the current transaction?
>
Nope, in this scheme we are avoiding Schnorr signatures entirely.
> That still leaves me confused. If ECDSA can be implemented within
> tapscript, then I would expect that schnorr could also be implemented within
> tapscript; that gives you an OP_CSFS equivalent. If being able to implement
> ECDSA in tapscript allows introspection, then I would expect implementing
> schnorr in tapscript would allow introspection; that gives you an OP_CAT
> equivalent. If you have OP_CSFS and OP_CAT, you have covenants and there's
> no need for lamport signatures or ECDSA.
>
Implementing ECDSA in Tapscript *only* allows introspection in
conjunction with the ability to force a user to spend a Tapscript output
alongside a pre-Tapscript output containing the same ECDSA signature.
And I am waving my hands and saying that I think you can force this by
using covenant tricks.
> Apologies for my remaining confused in the face of something that's probably
> obvious,
>
Lol. This whole thing is kinda insane.
--
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/Zjo72iTDYjwwsXW3%40camus.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-05-07 14:38 UTC|newest]
Thread overview: 23+ 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
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 [this message]
2024-05-09 0:31 ` Ben Carman
2024-05-09 12:46 ` Andrew Poelstra
2024-05-11 2:53 ` Antoine Riard
[not found] ` <91ba7058-776d-4ff0-a179-bb2917ef03ffn@googlegroups.com>
[not found] ` <CAEM=y+UKgDRtaV5uveiX_Hn1dTDEF-DSHw0SjRu+j0s3fmp78Q@mail.gmail.com>
[not found] ` <CAOY=fzk+nKBw4kpLJLe=EngNfD5iEsWVsa5sMyPaXKp9cDAqdQ@mail.gmail.com>
[not found] ` <CAOY=fz=bcun5U75PUJJGuuB7p5dHtghrYf9gfOvj4zpiWdM_Tg@mail.gmail.com>
2024-10-25 0:20 ` Vicky
2024-10-25 9:58 ` Garlo Nicon
2024-11-15 21:54 ` Xiaohui Liu
2024-11-16 14:55 ` Ethan Heilman
[not found] ` <CAMrCH3hCN0KAiE0AdLTA8i004-R9FACpMZvQTiM_78RAxf1zbA@mail.gmail.com>
2024-11-17 21:59 ` Ethan Heilman
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=Zjo72iTDYjwwsXW3@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=dave@dtrt$(echo .)org \
--cc=eth3rs@gmail$(echo .)com \
--cc=pinheadmz@gmail$(echo .)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