Hi list,

The delving thread on silent payments light clients
(https://delvingbitcoin.org/t/silent-payments-light-client-protocol/891)
stalled in mid-2024 waiting on numbers. I measured them, and can't post on
delving yet (new account), so here they are.

Setup: I've been running a BlindBit Oracle v2
(https://github.com/setavenger/blindbit-oracle) on mainnet since Sept 1, 
full
range from taproot activation, checked against the bips reference
implementation on sampled blocks and against oracle.setor.dev at every
height both serve.

All 255,434 blocks (709,656 to 965,089), no sampling:

- Full serving index: 109 GB (the often-quoted 1.7-2.8 GB is tweak storage
  only). 187,814,353 tweaks total, avg 735/block, ~6.2 GB raw. Index build
  took about 2h on 8 cores from local Core REST.

  mechanism                      total      avg/block    per day at tip
  BIP-158 basic filter           5.78 GB    22.6 KB      2.8 MB
  taproot-only filter (2024)     0.94 GB     3.7 KB      0.4 MB
  v2 compute-index payload      15.08 GB    59.0 KB      8.0 MB

josibake asked in that thread what a taproot-only filter saves over stock
BIP-158: about 6.1x overall, 3.2x at the inscriptions peak. I validated the
GCS size formula by actually encoding 21 real blocks; it's within 0.5%.

The other comparison matters more now: the v2 oracle that actually ships
dropped filters entirely and serves txid + tweak + output-prefixes instead.
A filter client still needs the raw tweaks (6.2 GB) plus a full block per
match, so a complete filter stack is ~7.1 GB against v2's 15.1 GB. In other
words v2 pays about 2.1x the bytes for zero false positives and no
per-match block fetches. Nobody had numbers on either side of that until
now.

Per-block CSVs and reproduction scripts:
https://github.com/bitsagarob/silentpayments-measurements

Spec drift, already filed with both spec repos
(https://github.com/setavenger/BIP0352-light-client-specification/issues/2,
https://github.com/silent-payments/BIP0352-index-server-specification/pull/1):
v2 has no filter endpoints, spent outputs are unsalted 8-byte x-only pubkey
prefixes where the spec says salted outpoint hashes, JSON is deprecated for
gRPC, and harding's full-block-on-match conclusion from the thread never
made it back into the spec text.

Last thing. The index-server spec asks how a wallet knows it received all
tweaks for a block. Today it can't, and a server that omits one silently
loses the receiver money. My oracle publishes per-block commitments
(sha256 over height, block hash, count, sorted tweak set, chained) and
checkpoints the head to nostr every 6 hours
(npub1wc5were3y63h4nwcckdrw72gceh4kgz8eg7fz0zrk2xufr4dx9xqlvmcx8).

Format spec and test vectors are in the repo above. This makes omission
attributable after the fact. It does not fix the targeted lying-server
attack harding described; clients should still fetch the full block on a
match. If a second server published the same digests, any two could be
cross-checked. Feedback on the serialization welcome before it ossifies.

Why I care about getting the canonical set right: if Core ever serves a
tweak index over P2P, a per-block digest chain is how peers get
cross-checked (the BIP-157 pattern), and a coinbase commitment would be
the version where nobody needs trusting at all. Every step of that ladder
uses the same canonical per-block set, so it seems worth agreeing on one
now while only a handful of servers exist.

Rob
silentpayments.net

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6871d475-fbd4-4455-954d-20a369fba471n%40googlegroups.com.