1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
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.
|
