Question from Martin, 2026-09-10. Answered against Pepecoin Core v1.1.0 source
(/home/martin/reference/pepecoin, tag v1.1.0, commit 4fb5a0cd).
Custom P2P messages: no — they won't propagate. But you don't need them: the mempool already is a network-wide broadcast channel.
Pepecoin inherits Bitcoin's 12-byte command field. An unrecognised command is tolerated:
else {
// Ignore unknown commands for extensibility
LogPrint("net", "Unknown command \"%s\" from peer=%d\n", ...);
}
verified in source code — src/net_processing.cpp:2852-2854
So you could send omnimsg to a connected peer and not get banned. But "ignore" means
exactly that: the node drops it and does not forward it. The full command set is fixed
(verified in source code, src/protocol.cpp:17-42): version, verack, addr, inv, getdata,
merkleblock, getblocks, getheaders, tx, headers, block, getaddr, mempool, ping, pong,
notfound, filterload/add/clear, reject, sendheaders, feefilter, sendcmpct, cmpctblock,
getblocktxn, blocktxn. Nothing free-form, nothing relayable.
Consequence: a custom message reaches only peers you connect to directly, and only ones running our software would act on it. That is not "one node to all others" — it is us building a private overlay while pretending it is Pepecoin's network. If we want an overlay, we should build one honestly, not smuggle it through a chain protocol that ignores it.
Unconfirmed transactions are gossiped network-wide, in seconds, via inv → getdata → tx.
That is a real peer-to-peer broadcast channel that already exists, already reaches every node,
and needs zero protocol changes.
An Omni message is just a transaction. Broadcast it and it propagates to the whole network
immediately; our Omni nodes see it via -zmqpubrawtx before it is ever mined.
| Custom P2P command | Mempool / transaction | Separate overlay net | |
|---|---|---|---|
| Reaches all nodes | ❌ direct peers only | ✅ whole network | ⚠️ only our nodes |
| Needs forked node | ✅ yes | ❌ no | ❌ no |
| Cost | free | tx fee (0.01 PEP/KB) | free |
| Ordered + consensus-verified | ❌ | ✅ once mined | ❌ |
| Permanent | ❌ | ✅ if mined | ❌ |
| Latency | instant | ~seconds unconfirmed, ~60 s mined | instant |
Recommendation: use transactions. Omni's anydata type 200 is literally a
general-purpose on-chain message and is the protocol-native answer. For anything that must be
free and ephemeral (peer discovery between our indexers, consensus-hash comparison chatter),
build a small separate overlay later — that is what Lightning and Counterparty both do rather
than abusing the base-layer P2P.
Caveat on ZMQ: Pepecoin v1.1.0 exposes zmqpubhashblock, zmqpubhashtx, zmqpubrawblock,
zmqpubrawtx (verified on host, pepecoind -help). There is no zmqpubsequence — that
is a Bitcoin 0.19+ feature and this codebase is 0.13-era. Reorg detection must therefore be done
by tracking previousblockhash ourselves rather than consuming sequence events. Noted as a
Phase 3 design constraint.