Add complete-witness tapscript execution and budget accounting - #23
Open
adrienlacombe wants to merge 1 commit into
Open
adrienlacombe wants to merge 1 commit into
adrienlacombe wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A tapscript execution initialized from only its data stack can reject a valid spend at the signature-budget boundary because BIP342 also counts the script, control block, annex and CompactSize prefixes. Add
Exec::new_tapscript(options, tx)to derive the execution context and50 + complete witness sizebudget from the selected transaction input. Existing explicit-script constructors retain their compatibility behavior.The constructor rejects malformed or inconsistent context, derives the annex for signature hashing, and requires the complete prevout list. It does not validate the Taproot output commitment, full transaction, relay policy or unsupported OP_SUCCESS behavior. Signature charges are now reflected in statistics even when the opcode fails.
Validation:
cargo test --locked --offline --workspace --all-featurespasses all 21 tests (11 existing unit tests, nine new regression tests and one doctest). The new tests cover all three signature opcodes at exact exhaustion and negative budgets, empty and failed signatures, real annex-bound Schnorr signatures, CompactSize boundaries, control-path sizes, malformed context, constructor compatibility and selection of input 1 from a two-input transaction. Upstream does not track Cargo.lock; an ignored lockfile was generated offline for this run.The accounting follows BIP342 and Bitcoin Core v30.3. This patch is based directly on upstream master and does not depend on the other pending interpreter repairs.
Independent funded validation is recorded in solving-bitcoin/bitcoin-scripts#240: all 32 complete-witness comparisons match Bitcoin Core v30.3, including rejection categories, and two fresh nodes produce identical reports. These runs use an integration that retains the existing interpreter repairs; the legacy and new constructors are compared at that same revision. Core accepts 15 spends under consensus and 10 under policy, while the legacy constructor disagrees on 16 cases.