From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 97F65C0032 for ; Tue, 24 Oct 2023 01:17:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 720E641960 for ; Tue, 24 Oct 2023 01:17:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 720E641960 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=ftGtfe3s 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 G9Vr4zhoniCa for ; Tue, 24 Oct 2023 01:17:30 +0000 (UTC) Received: from mail.wpsoftware.net (unknown [66.183.0.205]) by smtp2.osuosl.org (Postfix) with ESMTP id 4A6AD4012B for ; Tue, 24 Oct 2023 01:17:30 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4A6AD4012B Received: from camus (camus-andrew.lan [192.168.0.190]) by mail.wpsoftware.net (Postfix) with ESMTPSA id 777CE400C6; Tue, 24 Oct 2023 01:17:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net; s=default; t=1698110249; bh=FcCap2kd7NwOpSP0BgBw6fVDo7VwetGVvAst/dePL7M=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ftGtfe3sBL9P3lD12GTgKvD9smJFsLsO2dmqKFADwMKSzUu+HJh9/BRrLsa3V3BVb Bs70TMraXa46IJP+m5QZCNz33ffX0cE1KlxmCIyKPVBCZwVSSxpo+qiUmnkz/4MJ8A QQwngkqOnq15S66MAytI/6XaxjKjB8kxMGAkuHLBeCIsiGQ0dqOOGG/S+gx9xFvSho ElZuNxavLYnx4Qc0Q6z8B0DkqjiM0XtZ0vk7Vf38qBcqkO0uPbNsJLWpzSxI+zdtYG 4MHhKcouG6JAGaKwgTfks9EEHiP6r5KlbKn/zrRyqpEzI29DM37L+FVZEKCd1NoxzV YTplUFhoST/KQ== Date: Tue, 24 Oct 2023 01:17:28 +0000 From: Andrew Poelstra To: Rusty Russell Message-ID: References: <871qdmulvt.fsf@rustcorp.com.au> <871qdku9pj.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oYBV971ACDRmjKTB" Content-Disposition: inline In-Reply-To: <871qdku9pj.fsf@rustcorp.com.au> Cc: Bitcoin Protocol Discussion 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: Tue, 24 Oct 2023 01:17:31 -0000 --oYBV971ACDRmjKTB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2023 at 11:18:24AM +1030, Rusty Russell wrote: > Andrew Poelstra writes: > >> 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. >=20 > BTW, I'm just learning of the 1000 element limit; I couldn't see it on > scanning BIP-141. > This limit is very old and predates segwit. It might predate P2SH. > > 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. >=20 > Simplest thing I can come up with: >=20 > - instead of counting simple stack depth, count each stack entry as > (1 + /520) entries? You can still only push 520 bytes, so you > can only make these with OP_CAT. >=20 > 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. > I had a similar thought. But my feeling is that replacing the stack interpreter data structure is still too invasive to justify the benefit. Also, one of my favorite things about this BIP is the tiny diff. --=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 --oYBV971ACDRmjKTB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmU3GycACgkQxYjWPOQb l8FCngf+JTyBmW6E3+rLfgQh7B3baEcsRiHHxsCOUgSG/JHmd6xZaG1oiYulLDry mnefhmyJ+uhAAod+f+7Lsrutvbraotsto+vxoX84pQ+TIreRJL9OkslIdki6bH5W MemtkLUSB1sbNWvl0+ENrB5KacV87mU9HwhNKKggrDedHpDdVYRrc9/GOsFhTHiv SYkSEMGvExO4C16ywokybvsIevr8rCRUDhflHkBlzXW+48jL9cmIJ0ypgX0Y9qgO c2J0Pd+eIsqRgckcI7646DWqoM487hFDVNhjW94jaSWin1sOdfH237p8WECfwOPu 1RLJ7WnU0jkc+Gats+Rijj7bdvVE0g== =Jt3N -----END PGP SIGNATURE----- --oYBV971ACDRmjKTB--