Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id DBCB1C0DD7 for ; Mon, 23 Oct 2023 02:13:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 9F98241977 for ; Mon, 23 Oct 2023 02:13:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9F98241977 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=rustcorp.com.au header.i=@rustcorp.com.au header.a=rsa-sha256 header.s=202305 header.b=PPinOdLU X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.053 X-Spam-Level: X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRXnda98voGa for ; Mon, 23 Oct 2023 02:13:27 +0000 (UTC) Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by smtp4.osuosl.org (Postfix) with ESMTPS id AEE15418EB for ; Mon, 23 Oct 2023 02:13:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AEE15418EB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rustcorp.com.au; s=202305; t=1698027199; bh=Lc0HDlybxyv3S2TMEc8YOs/j9a1pxGanpBQf9xdTZyA=; h=From:To:Subject:In-Reply-To:References:Date:From; b=PPinOdLUQUCUXLp54hhTVePZ9Kf/HCKXdEcWZNvXHNzOMX1rITZZiBLbtc8K1MyNI pibMA85vrSTMd13dEj7kQEJmi4L3aRf+pPl8i7VVQ00sgG2G5W2J/3UqV3dxQT3qyP 73wzi3UKWWSHwKghD7p/lgE+y8ii5vP7mpgyU4Lw+9qHk0fCV0NQlwfQ86IhgpvzmW AqZ7J+o2cyxCWi/EJV1SzcFycVQjt4iZ0KFJr8XIFHqeps/dWbQtoSykGduJ1QoIuB gzvFQ5VNC0TCvlL4s2SjlszVB0pguVFYtG32z9bP9eM4aKmw/cMoC4sK28YasVu9+T lyQ2fxr83Nkaw== Received: by gandalf.ozlabs.org (Postfix, from userid 1011) id 4SDJdC0dT1z4x5k; Mon, 23 Oct 2023 13:13:19 +1100 (AEDT) From: Rusty Russell To: Ethan Heilman , Bitcoin Protocol Discussion , Bitcoin Dev In-Reply-To: References: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2023 02:13:29 -0000 Ethan Heilman via bitcoin-dev 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