dogecoin has a BIP157 client, a BIP158 index, and no node serving either

Of 48 addresses dogecoin's DNS seeds hand out, 48 answered a handshake and 0 advertised NODE_COMPACT_FILTERS. There is one BIP157 source on mainnet and it belongs to the person who wrote the client. The client is built, the index format already matches Core's, and a real application is waiting on it. What is missing is nodes willing to serve.

0 / 48

seed peers serving compact filters, all 48 reachable

run the payment channel see the measurements

koinu — a BIP157/158 client Syncs and verifies filters, and writes them in Core's own on-disk record format.

Dogecoin Core — the pull request Serves the filters. Not merged, and the only part that does not exist today.

payment-channel — something that needs them A merchant confirming a funding output in under three seconds, per customer, with no full node.

These were built separately and they meet at one question: is this output in the chain, buried, and unspent? A merchant has to answer it before shipping goods. A full node answers it instantly and carries 13.6 GB of UTXO set to do so. A filter client answers it from a bounded range of blocks. Nothing else answers it without trusting the person doing the paying.

measurements

Taken on dogecoin mainnet against one serving node. Filter counts and byte totals are exact. The sync time is one run on one machine and will vary.

0 of 48seed-returned peers advertising NODE_COMPACT_FILTERS, all 48 reachable

6,430,357mainnet filters synced from one BIP157 node in about 11 minutes, ~9,750/s

302.3 bytesper filter, 1,943,712,170 bytes total. Core's own cfilters.dat: 308.9

14,894 / 14,894records byte-identical to a real fltr00000.dat, 0 differing

100,000filters chained anchor to anchor, reproduced in an independent implementation

202,671,977UTXOs in 13,636,287,062 bytes, which is what a node carries to answer the same question

The fourth line is the one for a reviewer. koinu's on-disk record is Core's block filter index record: 32-byte hash, CompactSize length, filter. A merged pull request needs no new format, no conversion step and no second implementation to keep in sync.

the one question a merchant cannot answer alone

A payment channel lets a customer pay a merchant repeatedly off-chain and settle once. The merchant signs nothing he has not checked, and the one thing he cannot check himself is whether the funding output is real. Everything else is arithmetic he does locally. This is the single question that needs a chain.

bob: kw outpoint --daemon /run/kwd.sock --watch 2NFrH5n… --outpoint a109176…:0 --since 400
     unspent height 381 depth 6 value 10000000000 koinu   → ship the goods
     exit 3                                               → refuse, it is not there
     exit 4                                               → refuse, it did not look far enough back

Three seconds is the budget, per customer, because the customer is waiting on a socket. A client that syncs headers for itself does not fit: the header store alone wants 112 bytes a header, 684 MB at 6.4 M, and it is paid on every call. Filters are what make the question cheap. Without a peer serving them, the merchant's options are a full node or trusting the payer, and trusting the payer is the thing the protocol exists to avoid.

watch it refuse a replayed payment

the ask

Serve BIP157 and BIP158 from Dogecoin Core the way Core upstream already does, behind -blockfilterindex=1 and -peerblockfilters=1. The index format is already byte-compatible with what the client reads. An operator who turns it on pays for the index; everyone running a light client stops needing a full node to accept a payment.