From: "David A. Harding" <dave@dtrt•org>
To: Andrew Poelstra <apoelstra@wpsoftware•net>
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: Mon, 06 May 2024 18:11:48 -1000 [thread overview]
Message-ID: <93b8ed39b0aa3955eb9cb99f9fc5aae9@dtrt.org> (raw)
In-Reply-To: <ZjkqIzPSFLc0GJJ1@camus>
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?
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?
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.
Apologies for my remaining confused in the face of something that's
probably obvious,
-Dave
--
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/93b8ed39b0aa3955eb9cb99f9fc5aae9%40dtrt.org.
next prev parent reply other threads:[~2024-05-07 8:43 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
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 [this message]
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=93b8ed39b0aa3955eb9cb99f9fc5aae9@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--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