btcd

txscript: add initial awareness of new P2A output script

txscript: support trivial signing for P2A

txscript: recognize P2A witness program during script execution

In this commit, we modify the execution logic, such that the P2A witness
program doesn't appear as a unknown witness program version. For
execution, we just make sure the script passes.

mempool: add p2a specific policy

P2A is standard if the witness and the sigscript is empty. We make a
smol refactor to be able to write a unit test for the input
standardness.

txscript: add tests for new P2A awareness

btcjson: add Warnings field to GetBlockChainInfoResult

Bitcoin Core added a warnings field to getblockchaininfo in PR #10858,
and recently changed it from a string to an array in PR #29845. Add
the field using StringOrArray type to handle both formats.

This allows rpcclient to properly unmarshal getblockchaininfo responses
from all Bitcoin Core versions.

Closes #2444

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

btcjson: add tests for StringOrArray and Warnings field

Add a regression test for the StringOrArray.MarshalJSON infinite-recursion
fix that exercises both the direct method call and the path through
json.Marshal. Without the fix, the test triggers a goroutine stack
overflow.

Also add a round-trip test and tests for the new Warnings field on
GetBlockChainInfoResult, covering both the legacy single-string form and
the post-bitcoin#29845 array form.

btcjson: fix infinite recursion in StringOrArray.MarshalJSON

The MarshalJSON method was calling json.Marshal(h) where h is of type
StringOrArray. Since StringOrArray implements json.Marshaler, this
caused json.Marshal to call MarshalJSON again, resulting in infinite
recursion and a stack overflow.

Fix by converting to the underlying []string type before marshaling,
which breaks the interface lookup cycle.

Closes #2369

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

tests: fix stale regtest assumptions after #2467

PR #2467 changed regtest to match Core's BIP34/65/66 activation rules, and
the merged stack carries that (commit cd4e5426 "regtest: align activations
with Bitcoin Core"). Height-1 regtest blocks now need a BIP34-compliant
coinbase height and a post-BIP66 block version.

The failing tests came from commits added after PR #2467 was opened on
December 25, 2025 but before it merged on April 30, 2026:

- c1a46122 ("blockchain: add ProcessBlockHeader")
- f9645f07 ("blockchain: reuse existing header node in maybeAcceptBlock")
- dc6e096c ("netsync: add TestSyncStateMachine for end-to-end IBD sync flow")
- ce094262 ("netsync: add TestStartSyncBlockFallback for block-only sync path")
- 2aae8a6d ("netsync: add TestStartSyncChainCurrent for chain-current noop path")

Because those tests landed later, they kept the old regtest assumptions even
though #2467 had already been authored and tested against the older tree.
Once #2467 finally merged, these newer tests started building invalid regtest
blocks and headers.

Fix them by setting the genesis tip height to 0 before generating descendants,
using Version 4 in the regtest block/header helpers, and encoding the test
coinbase height with a minimal BIP34 push plus padding for the generic coinbase
script-length rule.

make fmt

rpcclient: avoid double-resolving POST requests on shutdown

When shutdown races with sendPostRequest, a request could be marked
as ErrClientShutdown and still be enqueued. The sendPostHandler cleanup
loop would then try to send a second terminal response and could block
forever on a full response channel.

Fix this by prioritizing the shutdown path. First check shutdown with a
non-blocking select and return immediately when it is already closed.
Then use a second select to choose between enqueue and shutdown for the
remaining race window.

A regression test verifies a shutdown request is failed immediately and
never enqueued.

rpcclient: avoid duplicate batch POST handlers

NewBatch called New() and then called start() again. In HTTP POST mode that
created a second sendPostHandler and another shutdown-cancel goroutine, which
broke the expected single-flight serialization of POST sends.

Keep NewBatch as a semantic toggle only: rely on New() to start handlers
once, then set batch=true. A regression test now checks that batch POST
requests stay serialized through one active transport call.

rpcclient: support canceling in-flight http requests

Use a shutdown-aware context for HTTP POST handling so shutdown can
interrupt in-flight requests.

Centralize shutdown error remapping in sendPostRequestAndRespond so all
error exits consistently return ErrClientShutdown when shutdown causes a
context cancellation. Move the retrying HTTP POST path into
sendPostRequestWithRetry and cover it with shutdown regression tests.

rpcclient: resolve all batch futures if Send fails

Batch requests were only clearing batchList on Send() errors. The
per-request futures remained unresolved, so callers waiting on Receive
could block forever after a failed batch round trip.

Add failBatchRequests to fan out the Send() error to every queued batch
request and clear tracking state in one place. A regression test now
verifies queued futures complete with the same error returned by Send().

txscript: support latest Core tx_invalid semantics

Handle BADTX sanity cases while keeping tx_invalid on Bitcoin Core's
included-flags convention.

txscript: support latest Core tx_valid semantics

Bitcoin Core's tx_valid vectors now specify flags to exclude from the
full script-flag set. Apply that parser directly in TestTxValidTests.

txscript: return ErrCleanStack for witness cleanstack failures

The refreshed Bitcoin Core script reference tests expect witness
clean-stack failures to report CLEANSTACK rather than a generic
EVAL_FALSE result.

txscript: support latest Core script_tests format

Add support for newly named Bitcoin Core script-test result tokens and
skip taproot placeholder rows that are already covered by
TestTaprootReferenceTests.

txscript: use finalOpcodeData for nested P2SH redeem script extraction

Both NewEngine and GetWitnessSigOpCount used sigScript[1:] (a raw byte
suffix of the scriptSig) to identify the candidate redeem script for
nested P2SH witness detection. GetPreciseSigOpCount and the existing
P2SH execution path already get the redeem script as the final pushed
element of the push-only scriptSig (via finalOpcodeData and
savedFirstStack[len-1] respectively). This commit consolidates the
nested-witness detection sites to use finalOpcodeData(0, scriptSig) so
all three places agree on what the redeem script is.

As a side effect of using the actual redeem script for detection, the
len(witness) != 0 precondition in NewEngine becomes redundant — the
redeem script's shape alone determines whether the spend is nested
witness, and verifyWitnessProgram already enforces the required
witness-stack shape downstream.

txscript: refactor CalcScriptInfo for nested P2SH analysis

Extract the nested P2SH analysis from CalcScriptInfo into a dedicated
calcP2SHScriptInfo helper, and switch it to use finalOpcodeData for
redeem-script extraction (matching the consolidation in NewEngine and
GetWitnessSigOpCount). The helper also threads the inner witness-script
expected-input contribution for nested P2WSH spends, which the previous
inline code did not account for.

txscript: align empty CHECKSIG pubkey validation with Core

The refreshed Bitcoin Core script reference tests cover cases where an
empty CHECKSIG input must still fail pubkey encoding checks before the
interpreter falls back to a generic false result.

txscript: update script_tests.json from Bitcoin Core

Updated from Bitcoin Core master
(e32bc7f817e7adeffef22a985bf8dbd4aa3e08d8), file
src/test/data/script_tests.json.

txscript: update tx_invalid.json from Bitcoin Core

Updated from Bitcoin Core master
(e32bc7f817e7adeffef22a985bf8dbd4aa3e08d8), file
src/test/data/tx_invalid.json.

txscript: update tx_valid.json from Bitcoin Core

Updated from Bitcoin Core master
(e32bc7f817e7adeffef22a985bf8dbd4aa3e08d8), file
src/test/data/tx_valid.json.

txscript: reject OP_CODESEPARATOR in unexecuted branches for non-segwit

In this commit, we fix a policy-level divergence with Bitcoin Core when
handling OP_CODESEPARATOR inside unexecuted OP_IF branches in non-segwit
scripts with the ScriptVerifyConstScriptCode flag.

Bitcoin Core's EvalScript (interpreter.cpp:474-476) places the
SCRIPT_VERIFY_CONST_SCRIPTCODE check for OP_CODESEPARATOR before the
fExec branch-execution gate, causing it to fire unconditionally on every
OP_CODESEPARATOR encountered during script iteration -- even inside
OP_FALSE OP_IF ... OP_ENDIF envelopes.

Previously, btcd's equivalent check lived inside the opcodeCodeSeparator
handler, which was never reached for opcodes in unexecuted branches due
to the early return in executeOpcode that skips non-conditional opcodes
when isBranchExecuting() is false. This meant a script like:

OP_FALSE OP_IF OP_CODESEPARATOR OP_ENDIF <validation>

would be rejected by Bitcoin Core's mempool but accepted by btcd's.

The fix moves the check before the branch-execution gate in
executeOpcode, matching Bitcoin Core's structure. This follows the
existing pattern in btcd where isOpcodeDisabled and isOpcodeAlwaysIllegal
checks already fire regardless of branch execution state.

Note: SCRIPT_VERIFY_CONST_SCRIPTCODE is purely a policy flag (included
in STANDARD_SCRIPT_VERIFY_FLAGS but not MANDATORY_SCRIPT_VERIFY_FLAGS),
so this was not a consensus divergence. Both implementations would accept
such transactions if mined in a block.

Found via differential fuzzing by Bruno from bitcoinfuzz.