Subject: Re: [bitcoindev] Signing a Bitcoin Transaction with Lamport Signatures (no changes needed)

From: "David A. Harding" <[email-masked]>
Date: Mon, 06 May 2024 18:11:48 -1000

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 [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/93b8ed39b0aa3955eb9cb99f9fc5aae9%40dtrt.org.