Node message types are absent from peer_registry

[echennells]

A node cannot send a block to a peer. The block is found and its size computed correctly, then zero bytes are written and the channel is dropped.

Present on master (9099a906, libbitcoin-node 2b377d16) in default configuration. This is the v1 transport; enable_privacy defaults to false.

Steps to trigger

1. Run bs with inbound connections enabled.
2. Connect a peer and complete the version/verack handshake.
3. Send getdata with MSG_BLOCK (or MSG_WITNESS_BLOCK) and the hash of a block the node holds.
4. The peer receives zero bytes and the node closes the connection.

MSG_TX on the same channel serves normally. bitcoind answers the same request with the block and stays connected.

Observed

Recv getdata from [...] (37 bytes)
Send block to [...] (285 bytes)
Send failure block to [...] (0 bytes) bad data stream
Inbound peer channel stop [...] bad data stream

Mechanism

channel_peer::send type-erases the message and carries a registry index instead:

out.message = rpc::any_t{ system::to_shared(message) };
out.index   = rpc::peer_registry::index_of<Message>();

peer_dispatch.hpp registers 35 types, all messages::peer::*; the only "block" entry is messages::peer::block. libbitcoin-node sends its own node::messages::block, which is not registered, so index_of returns unknown (= size = 35) and peer_registry::to_frame returns null. That becomes bad_stream and stops the channel.

The 285 in the log is message.size(), logged before serialization is attempted. index_of is constexpr, so nothing on the wire affects it.

Introduced by

01d95d9f "Write bip324 messages natively", which replaced serialization at the send site with the registry lookup. git log -S index_of -- channel_peer.hpp returns only this commit.

Why tests didn't catch it

Each registered message is tested here with index_of<T>() then commands().at(index), which throws for unknown. All 35 registered types have one. node::messages::block cannot have one — the test lives in the repo that has no knowledge of node's types.

libbitcoin-node's test/messages/block.cpp passes, because node::messages::block::serialize is correct in isolation; nothing calls it. Its test/protocols/protocol.cpp is BOOST_REQUIRE(true).

[evoskuil]

Style: Try to keep PR titles to one line (reign in your clanker).

Write bip324 messages natively

Yeah, that included a major refactor of the p2p impl to get it on to the body read/write model. Previously it worked great, I've fully synced from our own node to itself many times. We don't yet have the test suite set up for p2p as we do with the client-server connections (we should).

[evoskuil]

The fix isn't "register node's type" but "delete it". Somehow I got parallel block types in node and network as a result of the block_view work. The problem wasn't the Write bip324 messages natively commit, but the duplicate types that it exposed. This reaches back to your previous fix of witness behavior in block_view. That was a stale type that should have been deleted, with the correct behavior in network. The correct fix at that time, as now, is to delete the node types.

[evoskuil]

I'll patch this in node. I'm also adding a functional p2p test harness to mirror client-server tests in server, so we can prevent these types of regressions. There will be a suite in network for its protocols and an additional suite in node for its.

[evoskuil]

libbitcoin/libbitcoin-node#1103
#863

merged, please confirm

[echennells]

Confirmed on master 23bc26c2, clean build, no local patches.

getdata for a block the node holds returns it and the channel stays up (285 bytes, matching bitcoind for the same block). The Send failure block (0 bytes) bad data stream line is gone, and MSG_TX is unaffected as before.

functional_p2p__get_data__genesis_block__expected_bytes passes on that tree.