From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 02 Sep 2026 03:22:04 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1x1i6V-0007g7-Mm for bitcoindev@gnusha.org; Wed, 02 Sep 2026 03:22:04 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-469debb526fsf914703fac.0 for ; Wed, 02 Sep 2026 03:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1788344517; x=1788949317; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=cAhBe7DTdyOWfRtXX3UtLDKXRyGalsrWXJOip70Dei4=; b=iLZ08wu8SgoHIr4f1YHKr0h0b6fSvIW6gvXKH5iKTlnGPetsa+/nref4dsNKq+jx7T 7on8HvBsbl1nsszEjbSCWfV47IjSldagQyEvbB440gkWKQL8O+QLiKtx51H0CZCatnv5 0NasNMx/l/M/pO4QI4eLyU+9kBvdEHWb4KcojsY0n4zYjxZZ2CeOTd/uX+Ud7cbelEXM vzWRWffsD7XhRgbTxB3VWGdDUZaGi1N7FdWFuPTsX1vOUEhOU0Jh+3SPuT/3GZ2/guKz 9Br9zee8YajKciW/+dUGCXT4Df8rPmQAa0MBg9Mw87TywKfTvv/3m1bqhNjWzQItfPhX 7cBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788344517; x=1788949317; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=cAhBe7DTdyOWfRtXX3UtLDKXRyGalsrWXJOip70Dei4=; b=Zp7xOdAIPHbtahWMoer4Jf5IXRcZFvLWhEJs6wh1h51SUdJeFfCPNPUE6BRSz5jp/S O0j1vm01qd472y2F7qh8WYQmddVijv+EcPNmha7qtXQs9QrQiBsi8TnpRPUrHrEVDeLD tIX5fnRD9O9i5T4hJ5izPStr4frF9G7wwS9Luiml2yWDvzRPpmlzfwbfAvCRUbk7cBA3 IPvdTpDm4YDzZPAastpGbPOLQBvNn+I4NJzYNENeRRQBaQQxCGHw3eGbqH/yO/bS6zj2 0CEE+T+SYlQ1tacRoUb1xN2499wt/biE8a4hxzleVxP192T+OwYdL+PrwRSIOKB7CRBB qqmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788344517; x=1788949317; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=cAhBe7DTdyOWfRtXX3UtLDKXRyGalsrWXJOip70Dei4=; b=pPvc0Vqa87kUsLJA4YOK1n8XoWmR8W56vWiu6x6577CajSotBeb0A2NL0QZfHrnbrz LLY/p2vUZnjNwZOp0JpggqEetpk+7ob7Wx0ThIpnBWz36l7IuY6V0p+ZbwfVo9GfQ+Zz 5PBaIRwNEAUI842vOM8IXswG5iYjZsjJwiiAFszObcUG3vaAdHazHj8jsdgCdOheDc/p YQh5/DQLmE5lPabubwHEdyjdhOPeTi4nHgS7WJmsjuwHrhVnqzVcY8OaPfeZhjhKr0I2 any4E/Dkps64FVUk1IBhXwt8uIXDdHOJkwmzKuFyrrdYJjbkrhwcl0VW/LUL5v5hW/bK DfNQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+Ro/K09hSgo89+JAwBnrwWYz/9tr4Q+VVofwfoT7aX07ACR3DqbM/GfHV2GCmdXhqMTvbFDltPswAdeD@gnusha.org X-Gm-Message-State: AFuF++kd//MOKXx2Bw5uxA5zfNYVamDmT3uM2y1CHCrja9ntLGP5klIs jEcs4Mzxh6XR1JkqaZXmiJgxLs3Le2zLOlo+n8w9MFhE3/jC5VtCKWfU X-Received: by 2002:a05:6870:1435:b0:45e:da16:d128 with SMTP id 586e51a60fabf-46f85abf125mr3324408fac.7.1788344517061; Wed, 02 Sep 2026 03:21:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLde+jt8d6yqUb8HDe/d9PoNrgq4zE3Lizy1xB4j6ms6yVA==" Received: by 2002:a05:6870:8321:b0:46a:c883:a894 with SMTP id 586e51a60fabf-46ac883a9d1ls5225861fac.1.-pod-prod-05-us; Wed, 02 Sep 2026 03:21:52 -0700 (PDT) X-Received: by 2002:a05:6808:23ca:b0:4a4:ed9a:e7ac with SMTP id 5614622812f47-4b6bc444ecfmr3287618b6e.1.1788344512341; Wed, 02 Sep 2026 03:21:52 -0700 (PDT) Received: by 2002:a05:690c:a7cf:b0:848:c909:19b5 with SMTP id 00721157ae682-8607f321a77ms7b3; Wed, 2 Sep 2026 02:52:31 -0700 (PDT) X-Received: by 2002:a05:690c:e206:10b0:857:b539:c43f with SMTP id 00721157ae682-86c5339911cmr12338907b3.26.1788342751187; Wed, 02 Sep 2026 02:52:31 -0700 (PDT) Date: Wed, 2 Sep 2026 02:52:30 -0700 (PDT) From: Rob Segers To: Bitcoin Development Mailing List Message-Id: <6871d475-fbd4-4455-954d-20a369fba471n@googlegroups.com> Subject: [bitcoindev] Silent payments light clients: measurements and index commitments MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_49206_1505083951.1788342750915" X-Original-Sender: segersrobbert4@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_49206_1505083951.1788342750915 Content-Type: multipart/alternative; boundary="----=_Part_49207_1666963549.1788342750916" ------=_Part_49207_1666963549.1788342750916 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_49207_1666963549.1788342750916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list,

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

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

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

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

=C2= =A0 mechanism =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0total =C2=A0 =C2=A0 =C2=A0avg/block =C2=A0 =C2=A0per day a= t tip
=C2=A0 BIP-158 basic filter =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5= .78 GB =C2=A0 =C2=A022.6 KB =C2=A0 =C2=A0 =C2=A02.8 MB
=C2=A0 taproot-= only filter (2024) =C2=A0 =C2=A0 0.94 GB =C2=A0 =C2=A0 3.7 KB =C2=A0 =C2=A0= =C2=A00.4 MB
=C2=A0 v2 compute-index payload =C2=A0 =C2=A0 =C2=A015.0= 8 GB =C2=A0 =C2=A059.0 KB =C2=A0 =C2=A0 =C2=A08.0 MB

josibake as= ked 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
G= CS size formula by actually encoding 21 real blocks; it's within 0.5%.

The other comparison matters more now: the v2 oracle that actually s= hips
dropped filters entirely and serves txid + tweak + output-prefixe= s 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 eithe= r side of that until
now.

Per-block CSVs and reproduction s= cripts:
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://gi= thub.com/silent-payments/BIP0352-index-server-specification/pull/1):
v= 2 has no filter endpoints, spent outputs are unsalted 8-byte x-only pubkey<= br />prefixes where the spec says salted outpoint hashes, JSON is deprecate= d for
gRPC, and harding's full-block-on-match conclusion from the thre= ad never
made it back into the spec text.

Last thing. The i= ndex-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
(npub1wc5were3y63h4nwcckdrw72gceh4kgz= 8eg7fz0zrk2xufr4dx9xqlvmcx8).

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

Why I ca= re 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-checke= d (the BIP-157 pattern), and a coinbase commitment would be
the versio= n where nobody needs trusting at all. Every step of that ladder
uses t= he 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/6871d475-fbd4-4455-954d-20a369fba471n%40googlegroups.com.
------=_Part_49207_1666963549.1788342750916-- ------=_Part_49206_1505083951.1788342750915--