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).
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
IBD for new nodes were broken due to the version handshake failing
between nodes that recognized wtxid based relays. Reverting the changes
that were made so that the node is able to connect to those nodes.
* Add support for wtxidrelay message.
This adds support for the wtxidrelay (BIP339) message in wire.
While here, add tests for sendaddrv2 and rename AddrV2Version to
SendAddrV2Version in order to make the code consistent with all other
messages. This diff does keep the old AddrV2Version constant for
backwards compatibility.
* Bump copyrights
This is to mitigate CVE-2017-12842. Along the way, also error when
deserializing transactions that have the witness marker flag set
but have no witnesses. This matches Bitcoin Core's behaviour initially
introduced here https://github.com/bitcoin/bitcoin/pull/14039. Allowing
such transactions is benign, but this makes sure that our parsing code
matches Core's exactly.
In this commit, we update the top-level btcd package to use the latest
version of btcutil and also the chainhash package. With this version
bump, we can now use the new optimized dsha256 routine where applicable.
With this commit, I've covered most of the areas we'll hash an entire
transaction/block/header, but we may want to optimize some other areas
further, in particular, the witness sighash calc.
