May 22, 2026

it's a little different and worth mentioning: silent payments doesn't use an op_return for the shared secret, it uses the input public keys. this means you can't know whether a transaction is a silent payment unless you are the recipient. excellent for privacy, which was the goal (im one of the authors of the protocol). the trade-off is recipients must check every transaction with taproot outputs with an elliptic curve multiplication. for a public server supporting multiple cliente, this can be a heavy load on a server. the main thing frigate is doing is using GPUs for checking multiple transactions at a time for clients. could also be done with just CPU, but it's gonna be slow.

for someone using libbitcoin as a personal server, not at all a problem and way better than the current setup where someone would need to run frigate + bitcoind + an electrum server

Sure, in our indexing design we chose an op_return padded length that conflicted with more common op_return uses for this reason. Moving it into keys is obviously better hiding. But the rest is the same, the recipient still has to scan a huge number of txs with ec mult cost. But that can now be vectorized in GPUs, which has made it reasonable again. I dropped this index in bs in part because of the O(N) cost of every query. I talked with Craig about it last night. I think we could pick op the additional dependency conditionally for public deployment, it's pretty clean. But yeah, for personal use it's a much easier performance problem.

nice! if you're gonna go the GPU route, frigate is using ultrafastsecp. this means you could also do full verification on a gpu which i suspect would get your full validation closer to a milestone run in speed

Yes, I looked at it. Dependency-free C++ MIT, we could probably take it. It may not help much for validation, have to look into that. But we hate dependencies, and this is a big one.

Really you should be working on this with us.

would love to! if there's appetite from your team to review , id be happy to take a swing at it. full disclosure, im a bit overcommitted at the moment but should have more time in june

Yes, I'd really love to add this to our electrum interface. It's just one method, and the table/index is trivial. We could have all of the plumbing integrated in 2-3 days. I believe have all of the CPU primitives, well integrated and tested in nice C++ abstractions in libbitcoin-system.

I'd also like to have a realistic analysis of what this lib can do for signature validation. Like is it just a question of marshalling, or are their other issues.

If it made sense we could marshal millions of signatures at a time. But that's some work and we need to know what we can realistically get from it first.

The other aspect which might be worth looking at first, is personal server indexation.

Our priority has to be on getting v4 out, but would love to have this moving forward at the same time.