New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make script interpreter independent from storage type CScript #13062
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, will look more closely later.
src/span.h
Outdated
constexpr std::ptrdiff_t size() const noexcept { return m_size; } | ||
constexpr C& operator[](std::ptrdiff_t pos) const noexcept { return m_data[pos]; } | ||
|
||
constexpr Span<C> subspan(std::ptrdiff_t offset) const noexcept { return Span<C>(m_data + offset, m_size - offset); } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, equivalent to count = std::dynamic_extent
in std::span.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which is the default, so I think it's fine. Generally all methods here mimic a subset of the behaviour of std::span, but sometimes with optional arguments/types omitted.
Makes
Other changes look straightforward. utACK 91c12000dd97d7b9b9c82d1bbc92c7bbadd3d6ed |
This seems to be lacking a bunch of motivation. Can you clarify why you want to run a script stored in a span? |
@TheBlueMatt They're not stored in a Span; a Span is just a way to refer to a script stored anywhere (vector, array, prevector, whatever custom structure that can hold a continuous sequence of bytes). I'll add some more motivation. |
Suresure, I was asking for motivation of where we want to do this in the immediate future (do you have any branches that run scripts in non-prevector form?). The only place I can think of it being useful is in libbitcoinconsensus. |
@TheBlueMatt No code to show, but I added some thoughts to the PR description. |
Ah, the scriptPubKey/scriptSig distinction seems like a reasonable idea. Would love to see a branch with that implemented to see the feasibility of using this in the short-term after a merge. |
91c1200
to
de61601
Compare
Related discussion in IRC: https://botbot.me/freenode/bitcoin-core-dev/msg/99929791/ |
a76a044
to
6ae8a5d
Compare
Rebased. |
utACK 6ae8a5d |
6ae8a5d
to
ae8df82
Compare
utACK ae8df82ad34a6baaf883411308255e6c6d093c53 |
utACK ae8df82. |
re-utACK ae8df82ad34a6baaf883411308255e6c6d093c53 |
ae8df82
to
5fae0f4
Compare
Rebased. |
5fae0f4
to
2537e8a
Compare
… witness programs 34d0e07 Test that OP_1-OP_16 (but not lower/higher) start witness programs (Pieter Wuille) Pull request description: Cherry-picks one of the commits adding test coverage from #13062. As [pointed out by aj](https://github.com/bitcoin/bitcoin/pull/13062/files#r492723037): > could move the test additions to the first commit, since they're testing things that are already true Pull the additional test code into master earlier. ACKs for top commit: laanwj: Code review ACK 34d0e07 Tree-SHA512: ff0ab2a54613ea6e8246b443363b362dd41b5e464faba4d11be6003aa6588a626cf56e142a3b94465cd37dd3ac4debea08455db96bade336171b6c30ea894950
…) start witness programs 34d0e07 Test that OP_1-OP_16 (but not lower/higher) start witness programs (Pieter Wuille) Pull request description: Cherry-picks one of the commits adding test coverage from bitcoin#13062. As [pointed out by aj](https://github.com/bitcoin/bitcoin/pull/13062/files#r492723037): > could move the test additions to the first commit, since they're testing things that are already true Pull the additional test code into master earlier. ACKs for top commit: laanwj: Code review ACK 34d0e07 Tree-SHA512: ff0ab2a54613ea6e8246b443363b362dd41b5e464faba4d11be6003aa6588a626cf56e142a3b94465cd37dd3ac4debea08455db96bade336171b6c30ea894950
…) start witness programs 34d0e07 Test that OP_1-OP_16 (but not lower/higher) start witness programs (Pieter Wuille) Pull request description: Cherry-picks one of the commits adding test coverage from bitcoin#13062. As [pointed out by aj](https://github.com/bitcoin/bitcoin/pull/13062/files#r492723037): > could move the test additions to the first commit, since they're testing things that are already true Pull the additional test code into master earlier. ACKs for top commit: laanwj: Code review ACK 34d0e07 Tree-SHA512: ff0ab2a54613ea6e8246b443363b362dd41b5e464faba4d11be6003aa6588a626cf56e142a3b94465cd37dd3ac4debea08455db96bade336171b6c30ea894950
This introduces a version of GetScriptOp that is independent from the script storage type.
The CScript methods IsPayToScriptHash, IsWitnessProgram, and IsPushOnly are currently consensus critical, and dependent on the storage type (CScript). This creates new consensus-critical versions inside interpreter that operate on the more efficient Span<const unsigned char> type, independent from the script storage. The CScript methods remain, but are no longer consensus-critical.
This introduces a version of EvalScript that is independent from the storage type.
690bc61
to
f5ad705
Compare
Rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review ACK f5ad705
🐙 This pull request conflicts with the target branch and needs rebase. Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft". |
I think rebasing this to current master only requires: +++ src/script/interpreter.cpp
-+ return (CHashWriter(HASHER_TAPLEAF) << leaf_version << COMPACTSIZE(script.size()) << script).GetSHA256();
++ return (HashWriter(HASHER_TAPLEAF) << leaf_version << COMPACTSIZE(script.size()) << script).GetSHA256();
+++ src/psbt.h
@@ -889,7 +889,7 @@ struct PSBTOutput
} else if (key.size() != 33) {
throw std::ios_base::failure("Output Taproot BIP32 keypath key is not at 33 bytes");
}
- XOnlyPubKey xonly(uint256({key.begin() + 1, key.begin() + 33}));
+ XOnlyPubKey xonly(Span<const unsigned char>(key).subspan(1, 32)); |
Closing this as it has not had any activity in a while. If you are interested in continuing work on this, please leave a comment so that it can be reopened. |
This introduces versions of
GetScriptOp
,EvalScript
, andVerifyScript
that operate on scripts represented bySpan<const unsigned char>
. This makes it possible to use different representation types for scripts, as Spans can be used to refer to scripts stored in any continuous fashion in memory, regardless of the container.This is also a step towards reducing the consensus-criticalness of CScript, but not entirely. The interpreter code still uses CScript internally for a few purposes (notably
DecodeOP_N
, andoperator<<
).Longer term, the goal is removing the need for all scripts to share the same representation. Currently
CScript
is a prevector with 28 preallocated bytes - a choice we need because it's favorable for scriptPubKeys in the UTXO cache, but it's pretty terrible for storing scriptSigs. With this change, separate (or even custom) data structures can be used for UTXO scriptPubKeys, and scriptPubKeys/scriptSigs in transactions. One possibility for the latter is storing all scripts in a transaction concatenated in a single allocated area, rather than using separate allocations for each.