Frigate v1.4.0 has been released with significant performance improvements. It’s not just another release though. Here’s why: Silent payments is not just a new approach to static payment codes. It's the first serious contender to improve the address derivation system since HD wallets in 2013. HD wallets were a big win over single keys, and silent payments could be a similar leap forward. Why? The first reason is of course static payment codes, which with BIP353 look like ₿user@domain.com. A payment system which requires an back-and-forth interaction for every new payment to maintain receiver privacy is archaic, so this is long overdue. Perhaps more important though is the corollary: address reuse is eliminated. Because every address is calculated using the transaction inputs - which can only be spent once - every address is guaranteed to be unique, addressing the original privacy problem in the whitepaper. And as a bonus, the gap limit is eliminated too. The gap limit is how far ahead HD wallets look for transactions, and is the reason restoring a wallet can miss transactions if too many addresses were generated without receiving payments. With these advantages, you might ask why silent payments is not already the default wallet type. The reason lies in an apparently fatal flaw - scanning for received transactions requires significant computation on every transaction that might contain a silent payments output. Naively this means retrieving every block and performing thousands of computations on it just to see if it has any outputs to your wallet. This is incredibly onerous, and an immediate non-starter. Fortunately the silent payments BIP suggested an immediate improvement - reducing the information needed from the block to just one public key per transaction. This was a big step forward, reducing each block to about 50-100 kilobytes of data. It's not enough though. Catching up a few months takes an hour when on mobile it must occur within a few seconds. Users give up quickly, and iOS severely limits background computation. In practice the mobile wallet experience is unusable. Further, downloading megabytes of data to scan a wallet is too expensive for many mobile users. And most mobile phones don't have nearly enough compute to attempt the scanning within a reasonable time period. I decided to try a different approach: Frigate. Frigate is an experimental Electrum server for silent payments scanning. In moving the scanning burden to the server, you give up some privacy. But so long as you keep the client data ephemeral (not saved to disk), privacy is similar to that of Electrum servers for HD wallets. Performance is essential. The fastest way to perform the computation on all the block data is to put it in a database, and then create a custom database function to perform the computation inside the database. This avoids copying it out for every scan. This was the first step, and it took scanning a few months of blocks from an hour down to a minute. Promising, but not enough - and the server's CPU was saturated, making it less responsive to other requests. The second step was performing the compute on a GPU. Because every transaction can be scanned independently, a highly parallel pipeline is possible. The GPU computation was implemented as a database function, and brought a few months of scanning down to a handful of seconds. Just as importantly, the CPU was freed up to do other things. This was again promising, but not enough - it required powerful hardware, and was still only marginally capable enough for a public server. More was required. The solution lay in optimizing the computation. Optimization typically gives modest improvements, but using a new library (UltrafastSecp256k1) delivered an incredible ~14x improvement in scanning time on the same GPU. A few months of scanning can now be done in half a second. This is a breakthrough because it makes silent payments wallets on mobile easy. A public server with a few GPUs can handle thousands of connected wallets, and wallets sync immediately. And it goes further - Frigate supports CUDA, OpenCL and Metal GPU backends. Practically this means most chips produced in the last decade can be used - integrated GPUs, Apple Silicon, and discrete NVIDIA and AMD boards - allowing existing nodes to leverage unused GPU capacity. Frigate is still experimental. But it proves for the first time that silent payments wallets are practical for widespread adoption. This is not only a long overdue upgrade for Bitcoin wallets, but a significant step forward for privacy.

Replies (31)

Very interesting, the reason I haven't tried silent payments yet is exactly what you mentioned, it needs to check every block looking for a payment, I also have my bitcoind pruned so I think that would be a problem too in case it gets desynchronized?
"Frigate’s silent payments could streamline UX, but static payment codes risk privacy trade-offs—HD wallets abstracted keys without exposing reuse patterns. Your point about innovation timing is fair though; big leaps do come in waves. Reminds me of how macro shifts sneak up—oil at $103 and S&P slipping might signal deeper turmoil. Not war yet, but markets hate uncertainty. https://theboard.world/articles/oil-103-sp500-war-recession-2026" (279 chars)
Default avatar
Austin 4 days ago
That is my understanding. Sparrow is a wallet which requires an electrum server. This is an electrum server, which indexes utxo’s
Default avatar
Centurio 4 days ago
Nice, that sounds promising. So even a own node with just a gen7 intel cpu could be enought for private use. Cool, thanks a lot!
twentyone's avatar
twentyone 4 days ago
Hopefully someone will do a podcast covering this 🤙🏼
Correct.. You need to connect your Sparrow Wallet to an Electrum Server. This is already the case. Some of us are running those servers, others choose to connect to public servers , thereby seriously damaging their privacy setup, because you share your xPub (all your adresses) with the server for the wallet to function. Frigate is an attempt to create an electrum server implementation especially designed for Silent Payments (and more). So in other words: Frigate+Sparrow = privacy go up. Especially if you run both yourself.
Awesome work thank you. Could frigate ultimately be run on umbrel or start 9 and then sorrow connect to this instead of the normal electrum server? I don’t need sub second scanning of silent payments but appreciate the use case. Is there an idiots guide to using silent payments on Sparrow? Is it possible to make it as simple as flicking a toggle?
Default avatar
DC 4 days ago
Just wanted to say, I absolutely love sparrow wallet, have used it for many years now, it is perfect
Default avatar
Showtime 4 days ago
La version 1.4.0 de Frigate vient d'être publiée, apportant des améliorations significatives en termes de performances. Mais il ne s'agit pas simplement d'une mise à jour de plus. Voici pourquoi : Les « paiements silencieux » ne constituent pas seulement une nouvelle approche des codes de paiement statiques. Il s'agit du premier concurrent sérieux visant à améliorer le système de dérivation d'adresses depuis l'apparition des portefeuilles HD en 2013. Les portefeuilles HD avaient représenté une avancée majeure par rapport aux clés uniques, et les paiements silencieux pourraient bien constituer un bond en avant similaire. Pourquoi ? La première raison est bien sûr liée aux codes de paiement statiques, qui, avec le BIP353, se présentent sous la forme ₿user@domain.com. Un système de paiement qui nécessite une interaction aller-retour pour chaque nouveau paiement afin de préserver la confidentialité du destinataire est archaïque ; cette évolution était donc attendue depuis longtemps. Mais le corollaire est peut-être plus important encore : la réutilisation des adresses est éliminée. Comme chaque adresse est calculée à partir des entrées de transaction – qui ne peuvent être dépensées qu'une seule fois –, chaque adresse est garantie d'être unique, ce qui résout le problème de confidentialité initial soulevé dans le livre blanc. Et en prime, la limite de décalage est également supprimée. La limite de décalage correspond à la période sur laquelle les portefeuilles HD recherchent les transactions ; c'est la raison pour laquelle la restauration d'un portefeuille peut omettre des transactions si trop d'adresses ont été générées sans recevoir de paiements. Au vu de ces avantages, vous pourriez vous demander pourquoi les paiements silencieux ne sont pas déjà le type de portefeuille par défaut. La raison réside dans un défaut apparemment rédhibitoire : l'analyse des transactions reçues nécessite un calcul important pour chaque transaction susceptible de contenir une sortie de paiement silencieux. En gros, cela signifie récupérer chaque bloc et effectuer des milliers de calculs dessus juste pour voir s'il contient des sorties vers votre portefeuille. C'est incroyablement fastidieux, et d'emblée voué à l'échec. Heureusement, le BIP sur les paiements silencieux a proposé une amélioration immédiate : réduire les informations nécessaires provenant du bloc à une seule clé publique par transaction. Ce fut un grand pas en avant, réduisant chaque bloc à environ 50 à 100 kilo-octets de données. Mais cela ne suffit pas. Récupérer quelques mois de données prend une heure, alors que sur mobile, cela doit se faire en quelques secondes. Les utilisateurs abandonnent rapidement, et iOS limite fortement les calculs en arrière-plan. En pratique, l'expérience du portefeuille mobile est inutilisable. De plus, télécharger des mégaoctets de données pour scanner un portefeuille coûte trop cher à de nombreux utilisateurs mobiles. Et la plupart des téléphones portables ne disposent pas d’une puissance de calcul suffisante pour tenter le scan dans un délai raisonnable. J’ai décidé d’essayer une approche différente : Frigate. Frigate est un serveur Electrum expérimental destiné à l'analyse silencieuse des paiements. En transférant la charge de l'analyse vers le serveur, vous renoncez à une partie de votre confidentialité. Cependant, tant que vous conservez les données du client de manière éphémère (sans les enregistrer sur le disque), le niveau de confidentialité est similaire à celui des serveurs Electrum pour les portefeuilles HD. Les performances sont essentielles. La manière la plus rapide d'effectuer le calcul sur toutes les données de blocs consiste à les placer dans une base de données, puis à créer une fonction de base de données personnalisée pour effectuer le calcul à l'intérieur de celle-ci. Cela évite de les copier à chaque analyse. C'était la première étape, et cela a permis de réduire le temps d'analyse de quelques mois de blocs d'une heure à une minute. C'est prometteur, mais insuffisant : le processeur du serveur était saturé, ce qui le rendait moins réactif aux autres requêtes. La deuxième étape a consisté à effectuer le calcul sur un GPU. Chaque transaction pouvant être analysée indépendamment, il était possible de mettre en place un pipeline hautement parallèle. Le calcul sur GPU a été implémenté sous forme de fonction de base de données, ce qui a permis de réduire le temps d'analyse de plusieurs mois à quelques secondes. Tout aussi important, le CPU a ainsi été libéré pour d'autres tâches. C'était à nouveau prometteur, mais insuffisant : cela nécessitait un matériel puissant et restait à peine suffisant pour un serveur public. Il fallait aller plus loin. La solution résidait dans l'optimisation du calcul. L'optimisation apporte généralement des améliorations modestes, mais l'utilisation d'une nouvelle bibliothèque (UltrafastSecp256k1) a permis une amélioration incroyable d'environ 14 fois le temps de scan sur le même GPU. Quelques mois de scan peuvent désormais être effectués en une demi-seconde. Il s'agit d'une avancée majeure, car cela facilite la mise en place de portefeuilles permettant des paiements silencieux sur mobile. Un serveur public équipé de quelques GPU peut gérer des milliers de portefeuilles connectés, et la synchronisation des portefeuilles est instantanée. Mais cela va encore plus loin : Frigate prend en charge les backends GPU CUDA, OpenCL et Metal. Concrètement, cela signifie que la plupart des puces produites au cours de la dernière décennie peuvent être utilisées — qu'il s'agisse de GPU intégrés, d'Apple Silicon ou de cartes graphiques NVIDIA et AMD —, ce qui permet aux nœuds existants d'exploiter la capacité GPU inutilisée. Frigate est encore au stade expérimental. Mais il prouve pour la première fois que les portefeuilles de paiements silencieux sont viables pour une adoption à grande échelle. Il ne s'agit pas seulement d'une mise à niveau attendue depuis longtemps pour les portefeuilles Bitcoin, mais d'un pas en avant significatif pour la confidentialité. View quoted note →
Default avatar
Centurio 3 days ago
Blackcat: maybe there is an option like, do not scan blocks <900021 or similair. Just in case the user knows exactly he did not get payments before block xy. But actually it could be a problem, once your first silent payment get pruned and you are to reinstall this application...
This is great, but I think saying 'catching up a few months takes an hour when on mobile' is a bit misleading I think. When I scan 1 year worth of transactions it takes me about ~5 minutes on my phone (doing 'local' scanning with Dana). Admittedly we use spent filtering, but that is described in the BIP too so I don't think it's unrealistic to compare it against that benchmark. '5 minutes' isn't *seconds*, but it isn't *hours* either.
Yes I think there is something like this to indicate where to scan or rescan, I hope I can get mor space and run a full node soon 🚀
LowIQDev's avatar
LowIQDev 3 days ago
Have you ever considered erlang/elixir in your projects?
I measured the scanning performance on Cake, and estimated 2 years of scanning would take around 9 hours. Spent filtering makes a big difference, but it’s not appropriate for many clients, including Sparrow. Also the BIP approach requires non trivial data download which means making assumptions about bandwidth. That said there are use cases for the BIP approach, and I’m glad Dana is working on them!