From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Date: Tue, 24 Oct 2023 01:17:28 +0000 [thread overview]
Message-ID: <ZTcbKM+XTCaJ2kIP@camus> (raw)
In-Reply-To: <871qdku9pj.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
On Tue, Oct 24, 2023 at 11:18:24AM +1030, Rusty Russell wrote:
> Andrew Poelstra <apoelstra@wpsoftware.net> writes:
> >> 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.
>
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.
>
> 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.
>
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.
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-10-24 1:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-21 5:08 [bitcoin-dev] Proposed BIP for OP_CAT Ethan Heilman
2023-10-21 5:49 ` alicexbt
2023-10-21 15:03 ` Andrew Poelstra
2023-10-26 16:04 ` James O'Beirne
2023-10-21 16:10 ` Greg Sanders
2023-10-21 20:24 ` Ethan Heilman
2023-10-22 8:58 ` vjudeu
2023-10-24 19:47 ` Steven Roose
2023-10-26 1:53 ` Ethan Heilman
2023-10-23 2:13 ` Rusty Russell
2023-10-23 12:26 ` Anthony Towns
2023-10-23 13:41 ` Andrew Poelstra
2023-10-24 0:48 ` Rusty Russell
2023-10-24 1:17 ` Andrew Poelstra [this message]
2023-10-24 3:45 ` Rusty Russell
2023-10-24 13:05 ` Andrew Poelstra
2023-10-26 21:55 ` Peter Todd
2023-10-27 18:32 ` Anthony Towns
2023-10-23 5:13 vjudeu
2023-10-26 14:30 ` Ryan Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTcbKM+XTCaJ2kIP@camus \
--to=apoelstra@wpsoftware.net \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox