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.
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.
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.
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.
Add support for newly named Bitcoin Core script-test result tokens and
skip taproot placeholder rows that are already covered by
TestTaprootReferenceTests.
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.
This commit replaces the parsing of a JSON string with a simple
prefix/suffix replacement of the quotes. That is much faster than
allocating memory for a JSON parser.
Where possible, we also directly decode the hex with a decoder to
further reduce the number of allocations.
Add NewHashFromStrStrict and DecodeStrict for callers that must
parse full txids or block hashes exactly.
Keep NewHashFromStr and Decode lenient for compatibility, but add
NOTE docs steering typical parsing to the strict helpers.
Add tests for the new strict behavior and preserve coverage for the
existing lenient short and odd hex behavior.
As we introduced a new MaxProtocolMessageLength, MsgReject max size
should also be lowered to MaxProtocolMessageLength.
If this isn't lowered and if we ever have a MsgReject message that is
bigger than MaxProtocolMessageLength, then the MaxPayloadLength() check
on the message will pass but it won't serialize in functions
WriteMessageWithEncodingN() and WriteV2MessageN() as both of these
functions have a separate check that each message isn't greater than
MaxProtocolMessageLength.
Go's net.ParseIP stores IPv4 addresses as 16-byte IPv4-mapped IPv6
addresses (::ffff:x.x.x.x). NetAddressV2FromBytes dispatches on
address length, so these 16-byte addresses were incorrectly matched
as IPv6 and serialized with networkID 0x02 (IPv6) instead of 0x01
(IPv4). BIP-155 doesn't forbid this, but Bitcoin Core silently drops
them anyway (undocumented, naturally). Detect IPv4-mapped IPv6
addresses and extract the 4-byte IPv4 address with the correct
networkID.
Add a test case that passes a 16-byte IPv4-mapped IPv6 address
(::ffff:127.0.0.1) to NetAddressV2FromBytes and asserts that it
is recognized as IPv4 with networkID 0x01, not IPv6 with 0x02.
Revert MaxMessagePayload to 32MB and introduce MaxProtocolMessageLength
(~4MB) for p2p network message size enforcement. This mirrors Bitcoin
Core's separation between MAX_SIZE (32MB serialization bound) and
MAX_PROTOCOL_MESSAGE_LENGTH (~4MB network limit) introduced in
bitcoin/bitcoin#5843.
The previous commit reduced MaxMessagePayload to 4MB, but that constant
is also used as a serialization bound for deriving maxTxInPerMessage,
maxTxOutPerMessage, and variable-length string limits in contexts beyond
network messages (e.g. database deserialization via MsgTx.Deserialize).
While consensus limits keep real values well below the 4MB-derived
bounds, conflating the two constants is architecturally incorrect and
diverges from Bitcoin Core's design.
The new MaxProtocolMessageLength is now enforced in all four network
read/write paths: WriteMessageN, WriteMessageWithEncodingN,
ReadMessageWithEncodingN, and ReadV2MessageN (which previously had no
overall message size check).
In this commit, we remove the localhost-only restriction for sync peer
candidates on regtest and simnet. Previously, isSyncCandidate rejected
any regtest peer not on 127.0.0.1 or localhost, which prevented IBD
when nodes run in Docker containers on bridge networks (e.g. 172.18.0.x).
We also replace fragile pointer-equality checks against global chaincfg
params with value-based Name field comparisons, and extend the exception
to simnet since it has the same local-only usage pattern.
In this commit, we fix `IsRoutable` to correctly reject IPv6 addresses
whose first 16-bit group is zero (i.e., in the `0000::/16` reserved
block per RFC 4291). Differential fuzzing between btcd and Bitcoin Core
revealed that addresses like `0:9881:8181:8181:fe00🅰️9e:9801` were
slipping through as routable when they shouldn't be.
We add a new `zero6Net` (`0000::/16`) definition alongside the existing
`zero4Net`, and introduce an `IsZero` helper that checks both. The /16
prefix width is intentional: the broader /8 reservation would
incorrectly catch allocated sub-ranges like `0064:ff9b::/96` (RFC 6052,
NAT64). We also carve out an exception for RFC 6145 translated IPv4
addresses (`::ffff:0:0:0/96`), which live within `0000::/16` but are
valid for routing.
Test coverage includes the original bug report address, various
zero-prefix IPv6 addresses, the RFC 6145 exclusion, and corresponding
`GroupKey` entries to confirm they land in the "unroutable" bucket.
Fixes#2431
html/template automatically HTML-escapes special characters to prevent
XSS, which can silently corrupt arbitrary script data. Since the output
is binary script bytes and not HTML, this escaping provides no benefit
and might breaks correctness.
Add a recoverFromPanic method that catches panics in peer goroutines,
logs the error with a stack trace, and disconnects the offending peer
instead of crashing the entire node. This provides defense-in-depth
against future unknown panics in message parsing or handling.
Protect two goroutine boundaries:
- The negotiation goroutine in start(), which handles pre-handshake
message decoding via BtcDecode.
- The inHandler goroutine, which processes all post-handshake messages.
Refactor inHandler cleanup from manual end-of-function calls to
defer-based cleanup, ensuring close(p.inQuit) always runs even on
panic, which prevents stallHandler from hanging.
Add a bounds check against the remaining slab capacity so oversized
witness items return a decode error. Add a regression test for witness
items that overflow the decode slab.
This issue was discovered through differential fuzzing between btcd and
Bitcoin Core.
IPv4-mapped IPv6 addresses (::ffff:0:0/96, RFC 4291) sent with networkID
0x02 (IPv6) in addrv2 messages are now properly rejected. Per BIP155,
these addresses should use networkID 0x01 (IPv4) instead. This aligns
btcd's behavior with Bitcoin Core's addrv2 handling.
Changes:
- Add ipv4MappedPrefix constant for the ::ffff:0:0/96 prefix
- Add isIPv4Mapped() helper function to detect these addresses
- Update readNetAddressV2() to skip IPv4-mapped addresses with IPv6 networkID
- Add comprehensive test coverage for IPv4-mapped address detection
