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: Mon, 6 May 2024 16:48:17 +0000 [thread overview]
Message-ID: <ZjkJ0fPyzuAPTLWS@camus> (raw)
In-Reply-To: <47711dc4ffe9d661e8321b05b6adab4e@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]
On Sun, May 05, 2024 at 09:39:51PM -1000, David A. Harding wrote:
>
> Hi Andrew,
>
> I don't understand the above. I think of a covenant as a script that is
> able to restrict the scriptPubKey of the transaction that spends it. As I
> understand Heilman's description, a lamport signature commits to the size of
> an ECDSA signature (which can naturally vary) and the ECDSA signature
> commits to the spending transaction. Performing the lamport verification on
> the stack is practically equivalent to OP_CHECKSIGFROMSTACK, which is half
> of what you need for a covenant. As you've previously described[1], the
> other half is some method for introspection. How do lamport signatures
> offer introspection when they're restricted to committing to ECDSA
> signatures that can't be known at the time a script is created due to
> circular dependency in hashing (i.e., the ECDSA signature commits to the
> spending transaction, which commits to the previous transaction's txid,
> which commits to the script)?
>
Aside from limits on transaction size, post-Taproot script can verify a
trace of any program execution, as long as the individual elements it is
operating on fit into 4-byte CScriptNums. You can therefore implement
SHA2, ECDSA, etc., and reconstruct the pattern of SIZE elements by
feeding in transaction data. Which of course can then be arbitrarily
constrained.
Probably actually doing this would take more than 4 megs of script and
you would need to use some sort of BitVM tricks and the whole thing
might not work. But this was my point in saying that "only the script
limits are stopping us from having covenants".
And pre-Taproot we have only 201 opcodes so of course this is all
totally out of the question :) but plausibly we could make a copy of the
Lamport signature in a Taproot output and then use non-equivocation
slashing conditions to somehow make things work.
--
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/ZjkJ0fPyzuAPTLWS%40camus.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-05-06 16:59 UTC|newest]
Thread overview: 21+ 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
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 [this message]
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
[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
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=ZjkJ0fPyzuAPTLWS@camus \
--to=apoelstra@wpsoftware.net \
--cc=bitcoindev@googlegroups.com \
--cc=dave@dtrt.org \
--cc=eth3rs@gmail.com \
--cc=pinheadmz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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