diff options
| author | Rusty Russell <rusty@rustcorp.com.au> | 2023-10-24 11:18:24 +1030 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-10-24 00:48:46 +0000 |
| commit | dea536fcaa324a671794fdac164708ecff04fc7f (patch) | |
| tree | 37c65aacfce6dcdf8012453a6bf387373fbea0a2 /d6/ee7df919679abbe9cb896e0f01459c224d9316 | |
| parent | eb3656aeea5316269e479ceab65afafca68d022e (diff) | |
| download | pi-bitcoindev-dea536fcaa324a671794fdac164708ecff04fc7f.tar.gz pi-bitcoindev-dea536fcaa324a671794fdac164708ecff04fc7f.zip | |
Re: [bitcoin-dev] Proposed BIP for OP_CAT
Diffstat (limited to 'd6/ee7df919679abbe9cb896e0f01459c224d9316')
| -rw-r--r-- | d6/ee7df919679abbe9cb896e0f01459c224d9316 | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/d6/ee7df919679abbe9cb896e0f01459c224d9316 b/d6/ee7df919679abbe9cb896e0f01459c224d9316 new file mode 100644 index 000000000..34364d77d --- /dev/null +++ b/d6/ee7df919679abbe9cb896e0f01459c224d9316 @@ -0,0 +1,140 @@ +Return-Path: <rusty@gandalf.ozlabs.org> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 1B803C0071 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 24 Oct 2023 00:48:46 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id B98EE42CBB + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 24 Oct 2023 00:48:41 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B98EE42CBB +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=VT+2xzm/ +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 inHazq-_yVuu + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 24 Oct 2023 00:48:39 +0000 (UTC) +Received: from gandalf.ozlabs.org (mail.ozlabs.org + [IPv6:2404:9400:2221:ea00::3]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 2E50942CD6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 24 Oct 2023 00:48:37 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2E50942CD6 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rustcorp.com.au; + s=202305; t=1698108509; + bh=epaq2TC4lZee6M1anis7FlnjCC/kt/pr9czq2ebqhOk=; + h=From:To:Cc:Subject:In-Reply-To:References:Date:From; + b=VT+2xzm/dYVzhmhAUovX9Hf4y96rorB0fB5CYTmMgx5Tq+LqC1uDF1VDwVaIruUAn + Tjb9HUEZcIXG01ORPhor4hju4bsjHCW5sDTUyWjleymOLi/HGb6PbMETb5O+zKTdDY + 0123zuYkHYZc0ZFop7eIPxY8H/ciyYy23b4GxKfdG/8wBF7QOYRBEorF8CkfgNhJvS + qCqtWhsGC7Fkh3CvgSlcRiCL5X/B9eIzhuYNiCN1Eq0YgQU0RjEloHfBhRCrmFDUKn + 5IWFxV8ibv2yllQSZEvaq+NwlQGGoRE0txW2aILGVxSy0efIh6HH3kDuAetTr1cH7F + dG4BGJnylk8ZA== +Received: by gandalf.ozlabs.org (Postfix, from userid 1011) + id 4SDths44kgz4x2W; Tue, 24 Oct 2023 11:48:29 +1100 (AEDT) +From: Rusty Russell <rusty@rustcorp.com.au> +To: Andrew Poelstra <apoelstra@wpsoftware.net>, Bitcoin Protocol Discussion + <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <ZTZ4H2y6+5pxRcs/@camus> +References: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com> + <871qdmulvt.fsf@rustcorp.com.au> <ZTZ4H2y6+5pxRcs/@camus> +Date: Tue, 24 Oct 2023 11:18:24 +1030 +Message-ID: <871qdku9pj.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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 24 Oct 2023 00:48:46 -0000 + +Andrew Poelstra <apoelstra@wpsoftware.net> writes: +> 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 +>> +>> 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. + +I haven't yet found a desire for rolling sha2: an `OP_MULTISHA256` has +been sufficient for my templating investigations w/ OP_TXHASH. In fact, +I prefer it to OP_CAT, but OP_CAT does allow your Schnorr sig trick :) + +>> 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 :)). + +It's probably worth *thinking* about, yes. + +>> 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. + +BTW, I'm just learning of the 1000 element limit; I couldn't see it on +scanning BIP-141. + +> 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. + +Simplest thing I can come up with: + +- instead of counting simple stack depth, count each stack entry as + (1 + <size>/520) entries? You can still only push 520 bytes, so you + can only make these with OP_CAT. + +Looking in interpreter.cpp, `stack` and `altstack` now need to be +objects to count entries differently (not vectors), but it seems like +it'd be simple enough, and the logic could be enabled unconditionally +since it Cannot Be Violated prior to OP_CAT. + +Cheers, +Rusty. + |