From: Rusty Russell <rusty@rustcorp•com.au>
To: Andrew Poelstra <apoelstra@wpsoftware•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
Date: Tue, 24 Oct 2023 14:15:49 +1030 [thread overview]
Message-ID: <87r0lksmxe.fsf@rustcorp.com.au> (raw)
In-Reply-To: <ZTcbKM+XTCaJ2kIP@camus>
Andrew Poelstra <apoelstra@wpsoftware•net> writes:
> 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.
To be fair, this diff is even smaller than the OP_CAT diff :)
Though I had to strongly resist refactoring, that interpreter code
needs a good shake! Using a class for the stack is worth doing anyway
(macros, really??).
diff --git a/src/script/interpreter.cpp b/src/script/interpreter.cpp
index dcaf28c2472..2ee2034115f 100644
--- a/src/script/interpreter.cpp
+++ b/src/script/interpreter.cpp
@@ -403,6 +403,19 @@ static bool EvalChecksig(const valtype& sig, const valtype& pubkey, CScript::con
assert(false);
}
+// First 520 bytes is free, after than you consume an extra slot!
+static size_t effective_size(const std::vector<std::vector<unsigned char> >& stack)
+{
+ size_t esize = stack.size();
+
+ for (const auto& v : stack)
+ {
+ if (v.size() > MAX_SCRIPT_ELEMENT_SIZE)
+ esize += (v.size() - 1) / MAX_SCRIPT_ELEMENT_SIZE;
+ }
+ return esize;
+}
+
bool EvalScript(std::vector<std::vector<unsigned char> >& stack, const CScript& script, unsigned int flags, const BaseSignatureChecker& checker, SigVersion sigversion, ScriptExecutionData& execdata, ScriptError* serror)
{
static const CScriptNum bnZero(0);
@@ -1239,7 +1252,7 @@ bool EvalScript(std::vector<std::vector<unsigned char> >& stack, const CScript&
}
// Size limits
- if (stack.size() + altstack.size() > MAX_STACK_SIZE)
+ if (effective_size(stack) + effective_size(altstack) > MAX_STACK_SIZE)
return set_error(serror, SCRIPT_ERR_STACK_SIZE);
}
}
next prev parent reply other threads:[~2023-10-24 3:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-21 5:08 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
2023-10-24 3:45 ` Rusty Russell [this message]
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=87r0lksmxe.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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