Your anonymity set is much smaller than you think it is. 70% of spendable outputs are sent to previously used addresses. Data by @Bitcoin Research Kit.

https://bitview.space/charts/network/addresses/reused/outputs/share/1y

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 ₿[email protected]. 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.

https://github.com/sparrowwallet/frigate

Sparrow v2.4.2 has been released to fix issues in the transaction editor and improve certificate pinning for TLS connections.

Support has also been added for v3 transactions in the transaction editor.

Changelog here: https://github.com/sparrowwallet/sparrow/releases/tag/2.4.2

https://sparrowwallet.com/download/

Sparrow v2.4.1 has been released to fix higher CPU usage on some platforms due to a screen layout issue.

In addition, it's now possible to configure a custom wallets directory by opening a wallet from a non-default location.

Changelog here: https://github.com/sparrowwallet/sparrow/releases/tag/2.4.1

https://sparrowwallet.com/download

Sparrow v2.4.0 released with:

Send to silent payments hardware wallet support
Address display chunking
Wallet discovery for USB hardware wallets
Codex32 support
Trezor Safe 7, Ledger Nano Gen5,
Keycard and Keycard Shell support

https://github.com/sparrowwallet/sparrow/releases/tag/2.4.0

https://sparrowwallet.com/download