From: Rusty Russell <rusty@rustcorp.com.au>
To: Ethan Heilman <eth3rs@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Date: Mon, 23 Oct 2023 12:43:10 +1030 [thread overview]
Message-ID: <871qdmulvt.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
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?
2. Was there a concrete rationale for maintaining 520 bytes? 10k is the current
script limit, can we get closer to that? :)
3. Should we restrict elsewhere instead? After all, OP_CAT doesn't
change total stack size, which is arguably the real limit?
Of course, we can increase this limit in future tapscript versions, too,
so it's not completely set in stone.
Thanks!
Rusty.
[1] Maybe others are Bitcoin Core fluent, but I found it weird that
it's not simply `valtype vch1 = popstack(stack);`,
and `vch3.reserve(vch1.size() + vch2.size());` was just a weird detail.
[2] https://rusty.ozlabs.org/2023/10/22/amounts-in-script.html
next prev parent reply other threads:[~2023-10-23 2:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-21 5:08 [bitcoin-dev] Proposed BIP for OP_CAT 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 [this message]
2023-10-23 12:26 ` Anthony Towns
2023-10-23 13:41 ` Andrew Poelstra
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=871qdmulvt.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=eth3rs@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