From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Rusty Russell <rusty@rustcorp•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Date: Mon, 23 Oct 2023 13:41:51 +0000 [thread overview]
Message-ID: <ZTZ4H2y6+5pxRcs/@camus> (raw)
In-Reply-To: <871qdmulvt.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> Ethan Heilman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes:
> > Hi everyone,
> >
> > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> > https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
>
> This is really nice to see!
>
> AFAICT you don't define the order of concatenation, except in the
> implementation[1]. I think if A is top of stack, we get BA, not AB?
>
> 520 feels quite small for script templates (mainly because OP_CAT itself
> makes Script more interesting!). For example, using OP_TXHASH and
> OP_CAT to enforce that two input amounts are equal to one output amount
> takes about 250 bytes of Script[2] :(
>
> So I have to ask:
>
> 1. Do other uses feel like 520 is too limiting?
In my view, 520 feels limiting provided that we lack rolling sha2
opcodes. If we had those, then arguably 65 bytes is enough. Without
them, I'm not sure that any value is "enough". For CHECKSIGFROMSTACK
emulation purposes ideally we'd want the ability to construct a full
transaction on the stack, which in principle would necessitate a 4M
limit.
> 2. Was there a concrete rationale for maintaining 520 bytes? 10k is the current
> script limit, can we get closer to that? :)
But as others have said, 520 bytes is the existing stack element limit
and minimizing changes seems like a good strategy to get consensus. (On
the other hand, it's been a few days without any opposition so maybe we
should be more agressive :)).
> 3. Should we restrict elsewhere instead? After all, OP_CAT doesn't
> change total stack size, which is arguably the real limit?
>
Interesting thought. Right now the stack size is limited to 1000
elements of 520 bytes each, which theoretically means a limit of 520k.
Bitcoin Core doesn't explicitly count the "total stack size" in the
sense that you're suggesting; it just enforces these two limits
separately.
I think trying to add a "total stack size limit" (which would have to
live alongside the two existing limits; we can't replace them without
a whole new Tapscript version) would add a fair bit of accounting
complextiy and wind up touching almost every other opcode...probably
not worth the added consensus logic.
> Of course, we can increase this limit in future tapscript versions, too,
> so it's not completely set in stone.
>
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-10-23 13:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-21 5:08 Ethan Heilman
2023-10-21 5:49 ` alicexbt
2023-10-21 15:03 ` Andrew Poelstra
2023-10-26 16:04 ` James O'Beirne
2023-10-21 16:10 ` Greg Sanders
2023-10-21 20:24 ` Ethan Heilman
2023-10-22 8:58 ` vjudeu
2023-10-24 19:47 ` Steven Roose
2023-10-26 1:53 ` Ethan Heilman
2023-10-23 2:13 ` Rusty Russell
2023-10-23 12:26 ` Anthony Towns
2023-10-23 13:41 ` Andrew Poelstra [this message]
2023-10-24 0:48 ` Rusty Russell
2023-10-24 1:17 ` Andrew Poelstra
2023-10-24 3:45 ` Rusty Russell
2023-10-24 13:05 ` Andrew Poelstra
2023-10-26 21:55 ` Peter Todd
2023-10-27 18:32 ` Anthony Towns
2023-10-23 5:13 vjudeu
2023-10-26 14:30 ` Ryan Grant
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=ZTZ4H2y6+5pxRcs/@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rusty@rustcorp$(echo .)com.au \
/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