# Can Omni nodes message each other over Pepecoin's P2P network?

Question from Martin, 2026-09-10. Answered against Pepecoin Core v1.1.0 source
(`/home/martin/reference/pepecoin`, tag v1.1.0, commit `4fb5a0cd`).

## Short answer

**Custom P2P messages: no — they won't propagate.**
**But you don't need them: the mempool already is a network-wide broadcast channel.**

## Why custom P2P messages don't work

Pepecoin inherits Bitcoin's 12-byte command field. An unrecognised command is *tolerated*:

```cpp
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.

## What does work: the mempool

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.