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>
In-Reply-To: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
References: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
Date: Mon, 23 Oct 2023 12:43:10 +1030
Message-ID: <871qdmulvt.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Precedence: list

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