Parallel Silent Payment index

[Sjors]

Based on:

• BIP352 index (for light wallets and consistency check) #86
• index: initial sync speedup, parallelize process bitcoin/bitcoin#26966

Usage

build/bin/bitcoin node -bip352index -indexworkers=10

Caveats:

• it current segfaults :-)
• I had to resolve a conflict between BIP352 index (for light wallets and consistency check) #86 index: add start_height to base index and index: initial sync speedup, parallelize process bitcoin/bitcoin#26966 index: implement index parallel sync

[Sjors]

@furszy I rebased on the latest #86 and the latest commits from bitcoin#26966. I then used b8883fa from your branch. But it still segfaults. Maybe I missed something?

2025-07-25T12:40:51.364698Z txindex thread start
2025-07-25T12:40:51.364730Z txindex thread exit
2025-07-25T12:40:51.364773Z threadpool_worker_0 thread start
2025-07-25T12:40:51.364823Z bip352 index thread start
zsh: segmentation fault  build/bin/bitcoin node -nowallet -bip352index -indexworkers=1

[furszy]

@furszy I rebased on the latest #86 and the latest commits from bitcoin#26966. I then used b8883fa from your branch. But it still segfaults. Maybe I missed something?

It fails due to the custom start_height you have in this branch (1fb0a3c). During the rebase, dropped:

diff --git a/src/index/base.cpp b/src/index/base.cpp
--- a/src/index/base.cpp	(revision 0e75edb4e2c1242f541c6208cdf22d411cf22d7a)
+++ b/src/index/base.cpp	(date 1753454368355)
@@ -263,6 +263,13 @@
         return;
     }
 
+    // If pindex_next is our first block and we are starting from a custom height,
+    // set pindex to be the previous block. This ensures we test that we can still rewind
+    // from our custom start height in the event of a reorg.
+    if (pindex_next->nHeight == m_start_height && m_start_height > 0) {
+        pindex = pindex_next->pprev;
+    }
+
     // Handle potential reorgs; if the next block's parent doesn't match our current tip,
     // rewind our index state to match the chain and resume from there.
     if (pindex_next->pprev != pindex && !Rewind(pindex, pindex_next->pprev)) {

That being said, 1fb0a3c code seems a bit flaky during startup (what if the index receives a block through the validation events - it seems it will still try to connect it even when it is below the start_height) but will not review something is not meant to get merged in Core :).

[Sjors]

@furszy thanks. It doesn't need to be very robust, I'm just trying to measure the performance difference. And for the base index PR it's mainly about checking the SP crypto matches other implementations.

I think the way to really add new indexes, e.g. to help lite clients, is to have an IPC interface for external indexers.

[furszy]

I think the way to really add new indexes, e.g. to help lite clients, is to have an IPC interface for external indexers.

yeah, that's where bitcoin#24230 is heading to.

[Sjors]

I noticed a huge amount of disk reading on my spinning disk and it taking a long time before index actually started building. Added an early return to aseIndex::ProcessBlocks.

Despite the change it still spends 7 minutes rattling the disk before finally showing a "Syncing bip352 index with ..." log message. But it just continues the heavy disk i/o for at least another 10 minutes before I gave up.