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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <apoelstra@wpsoftware.net>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0E549C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Oct 2023 13:41:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id CF22C416BD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Oct 2023 13:41:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CF22C416BD
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=mail.wpsoftware.net
header.i=@mail.wpsoftware.net header.a=rsa-sha256 header.s=default
header.b=Xa5QbwJN
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fMRWXk-_T_aR
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Oct 2023 13:41:53 +0000 (UTC)
Received: from mail.wpsoftware.net (unknown [66.183.0.205])
by smtp2.osuosl.org (Postfix) with ESMTP id AE76C400CB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Oct 2023 13:41:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AE76C400CB
Received: from camus (camus-andrew.lan [192.168.0.190])
by mail.wpsoftware.net (Postfix) with ESMTPSA id E23D4400C6;
Mon, 23 Oct 2023 13:41:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net;
s=default; t=1698068512;
bh=zDaenZXqhsdXEjG8EkU93AVys+2OBA5ZcLOCTCTqe0c=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=Xa5QbwJNk3aWh82cgu7vUCkXhEE6EQFfrPGSBMDwH1QcEKVJp8KjFA6D/HzcX7+ue
W4Fwl/ipkPSLHZS7oTmXGxfP/rnO5ugK2V46V4CleL6Qwtb0yxKrXABpF5Zg5UGlRu
gsg58xHqutaXIUol1rcKc4RZgdzE9EdS6gJRzS4GWz3qc1tc/UU4RaniA56SlcVxOG
wMfGuyY8QJYMU76FsvUzBIVP5jUkA0Tza8rQP56SmpcbPmcHLpqClIsx9yeRrj2YkT
BzURtoCbZZN+yUB7ZS4NM/Ng0eiFnyg6Ds5uDQ3z1OpJHKlZzNGIu3aeAgeh6ow0mk
f1ZakNliGW15w==
Date: Mon, 23 Oct 2023 13:41:51 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZTZ4H2y6+5pxRcs/@camus>
References: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
<871qdmulvt.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="3WEIdbII5avoQcnW"
Content-Disposition: inline
In-Reply-To: <871qdmulvt.fsf@rustcorp.com.au>
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: Mon, 23 Oct 2023 13:41:55 -0000
--3WEIdbII5avoQcnW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wro=
te:
> Ethan Heilman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wri=
tes:
> > 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
>=20
> This is really nice to see!
>=20
> 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?
>=20
> 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] :(
>=20
> So I have to ask:
>=20
> 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.
> 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 :)).
> 3. Should we restrict elsewhere instead? After all, OP_CAT doesn't
> change total stack size, which is arguably the real limit?
>=20
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.
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.
> Of course, we can increase this limit in future tapscript versions, too,
> so it's not completely set in stone.
>=20
--=20
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--3WEIdbII5avoQcnW
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmU2eB0ACgkQxYjWPOQb
l8EFFAf+NAzdRUaz6coZN9SLhStuzqq8YW2bjBBz7MnZRwyIq8LiUBtXAxfhk0JG
UoMLG74qKsOg3pBfcFhnUgETBnAB5eIIp94jZAWq+vNBBU1s1O4DHoj9ebb5EfdI
pVu+4B/gqud7yxhKkNQtUiMWJy/Ao/OAyMb6RMvHoWWgJD6LYV1DgjQCdJ/GkUNO
QhSUWZqX7E78QM38p4SzysQPgCiS++eR9WitER5stXK0hDzZUHiwissdvZGcglF7
w7gu8hkRhDzP0z4qc86+Y85yJYDbML0o5WBfow0o1oaoT1P+JH9z15j/6BpwolFb
DckRkse5zXDff4C4GaQ+HhPUdA7eJQ==
=nct2
-----END PGP SIGNATURE-----
--3WEIdbII5avoQcnW--
|
