BIP352 Silent Payments Causing Server Slowdowns for Automated Nodes

2 replies 220 views
Posts: 13 · Reputation: 110
#1Apr 21, 2018, 06:51 AM
I'm trying to work with BIP352 silent payments, but it's totally wrecking my server performance. I have to scan every tweak, and the calculations are just overloading my Python script. When 3 or 4 blocks come in at the same time, my node completely crashes. The CPU hits 100% while it's doing those curve calculations, which makes us miss a bunch of regular zero-conf payments. Is there a smarter way to scale the view key scanning? Like maybe offloading mempool data to a separate Rust setup? Using core RPC for this just feels unreliable when there’s heavy traffic.
5 Reply Quote Share
paul.ninjaFull Member
Posts: 152 · Reputation: 539
#2Apr 21, 2018, 08:54 AM
Yeah, Python in the hot path for Silent Payments scanning is basically volunteering to get screwed by elliptic curve math. That part is not really a Bitcoin Core problem so much as an architecture problem. Core can be your data source, but I would not make it the place where your receiver logic goes to die. If you are handling real traffic, the scanner wants to live in a separate process, preferably Rust or C++ with libsecp256k1 doing the ugly lifting, and it should consume tx/block data as a stream, not by repeatedly poking RPC. What usually helps is splitting the system into two lanes. One lane handles your normal mempool / zero-conf logic and stays responsive. The other lane does the heavier Silent Payments scan asynchronously with its own queue, checkpoints, and backpressure so 3 or 4 blocks landing together does not turn the whole node into soup. Also, do not rescan full blocks unless you absolutely have to. Keep incremental state, cache whatever intermediate data is actually reusable, and let catch-up happen behind the scenes instead of blocking foreground payment handling. So yes, dumping the scan workload to a separate Rust box is a sane direction. I'd even say that is the adult way to do it. Core RPC is fine for coordination and retrieval, but if your design depends on Python chewing through every tweak fast enough during bursty block arrival, the design is already waving a little white flag.
4 Reply Quote Share
Posts: 13 · Reputation: 110
#3Apr 21, 2018, 11:43 AM
The adult way comment is too accurate lol. Ill rip the scanning logic out into a dedicated rust daemon this week. Trying to force python to do the heavy math here was a massive mistake.
4 Reply Quote Share
?Reply
Sign in to reply to this topic

Related topics