Skip to content

Commit 16b5220

Browse files
committed
Merge rust-bitcoin#3789: Add hash data to Inventory's Error variant
72e97c6 Add a hash value to Inventory's Error variant (Nick Johnson) Pull request description: I am working on adding BIP324 V2 p2p network message support to the p2p module and ran into a little snag. I can post a draft branch of that work if helpful, but the general strategy is to add a `V2NetworkMessage` which operates in parallel with the existing `RawNetworkMessage` type (which is a bit of misnomer and may be better described in the future as `V1NetworkMessage`, see rust-bitcoin#3157). This allows both p2p message types to hook into the existing `Encodable`/`Decodeable` chain. But the `Error` variant of the `Inventory` type message does not have symmetrical encoding and decoding paths. Encoding writes out a zero'd 32 bytes while decoding ignores it completely. And while it is not clear to me if there is [requirement written down](https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors) anywhere, [bitcoin core does appear to always expect a hash](https://github.com/bitcoin/bitcoin/blob/c1252b14d714448295200a595086dd3e78b46c8f/src/protocol.h#L499) even with the `Error` variant where it is meaningless. I believe rust-bitcoin's handling of this was never a problem before because the top level `RawNetworkPackage` pulls all the required bytes off a reader before decoding them. But this is not as easy to do with the v2 p2p network messages since the length is decoded at the transport level, not the message itself. I believe it is preferable for the Decoders to *not* assume that all bytes have been pulled off already given their input stream interface. Maybe somewhat surprisingly, this is the only issue I have run into so far adding the v2 encoding and decoding paths. As it is now, the code panics with an `Unconsumed` because it hasn't pulled the dummy zero bytes off the reader. This patch adds the 32 byte array to the Error variant in order to make its Encoding and Decoding paths symmetrical. This also allows a reader to discard the 32 bytes when decoding a message while cleanly keeping things hooked up with the `Decodeable` chain. The hash is still not exposed to the caller. This is *a way* to solve my issue, but not sure if it will cause more confusion than its worth. I tried a few other strategies, but preferred this one due to how well it hooks into `Decodeable`. ACKs for top commit: apoelstra: ACK 72e97c6; successfully ran local tests tcharding: ACK 72e97c6 Tree-SHA512: 20cb9fec0768e0fdf7c7f520a00e1a37f5ef0583e2ebc7d47583249c6829c47826d83694a56338efa5844a9fe264a77f6d04c0c46c85f8732c7585515723d7ce
2 parents 4cd7a5e + 72e97c6 commit 16b5220

File tree

2 files changed

+8
-7
lines changed

2 files changed

+8
-7
lines changed

bitcoin/src/p2p/message.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -583,7 +583,7 @@ mod test {
583583
)]),
584584
NetworkMessage::Inv(vec![Inventory::Block(hash([8u8; 32]).into())]),
585585
NetworkMessage::GetData(vec![Inventory::Transaction(hash([45u8; 32]).into())]),
586-
NetworkMessage::NotFound(vec![Inventory::Error]),
586+
NetworkMessage::NotFound(vec![Inventory::Error([0u8; 32])]),
587587
NetworkMessage::GetBlocks(GetBlocksMessage::new(
588588
vec![hash([1u8; 32]).into(), hash([4u8; 32]).into()],
589589
hash([5u8; 32]).into(),

bitcoin/src/p2p/message_blockdata.rs

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -16,8 +16,9 @@ use crate::transaction::{Txid, Wtxid};
1616
/// An inventory item.
1717
#[derive(PartialEq, Eq, Clone, Debug, Copy, Hash, PartialOrd, Ord)]
1818
pub enum Inventory {
19-
/// Error --- these inventories can be ignored
20-
Error,
19+
/// Error --- these inventories can be ignored.
20+
/// While a 32 byte hash is expected over the wire, the value is meaningless.
21+
Error([u8; 32]),
2122
/// Transaction
2223
Transaction(Txid),
2324
/// Block
@@ -42,10 +43,10 @@ pub enum Inventory {
4243
impl Inventory {
4344
/// Return the item value represented as a SHA256-d hash.
4445
///
45-
/// Returns [None] only for [Inventory::Error].
46+
/// Returns [None] only for [Inventory::Error] who's hash value is meaningless.
4647
pub fn network_hash(&self) -> Option<[u8; 32]> {
4748
match self {
48-
Inventory::Error => None,
49+
Inventory::Error(_) => None,
4950
Inventory::Transaction(t) => Some(t.to_byte_array()),
5051
Inventory::Block(b) => Some(b.to_byte_array()),
5152
Inventory::CompactBlock(b) => Some(b.to_byte_array()),
@@ -66,7 +67,7 @@ impl Encodable for Inventory {
6667
};
6768
}
6869
Ok(match *self {
69-
Inventory::Error => encode_inv!(0, [0; 32]),
70+
Inventory::Error(_) => encode_inv!(0, [0; 32]),
7071
Inventory::Transaction(ref t) => encode_inv!(1, t),
7172
Inventory::Block(ref b) => encode_inv!(2, b),
7273
Inventory::CompactBlock(ref b) => encode_inv!(4, b),
@@ -83,7 +84,7 @@ impl Decodable for Inventory {
8384
fn consensus_decode<R: BufRead + ?Sized>(r: &mut R) -> Result<Self, encode::Error> {
8485
let inv_type: u32 = Decodable::consensus_decode(r)?;
8586
Ok(match inv_type {
86-
0 => Inventory::Error,
87+
0 => Inventory::Error(Decodable::consensus_decode(r)?),
8788
1 => Inventory::Transaction(Decodable::consensus_decode(r)?),
8889
2 => Inventory::Block(Decodable::consensus_decode(r)?),
8990
4 => Inventory::CompactBlock(Decodable::consensus_decode(r)?),

0 commit comments

Comments
 (0)