pull down to refresh

My Second Thoughts on Silent Payments
1524 sats \ 7 comments \ @deSign_r 13 Oct bitdevs
There has been some progress in the Silent Payments development, the ecosystem seems slowly growing at pace since my First Thoughts on it, let's have a look.
Here on SN, the protocol has been mentioned multiple times:
  • #688894 Getting Started | Silent Payments (with BlueWallet and Cake on mobile)
  • #541840 All you need to know about Silent Payments in one site
  • #799341 Silent Payments?
  • #1005590 New booklet about silent payments
  • #754883 Bitcoin Silent Payments, a step in the right direction
From a dev perspective, here some npm packages and these are the only two libraries I found:

Wallets

Bitcoin Core is near to merge both, the send and receive functionalities. BlueWallet seems working on it, here a non-custodial bitcoin wallet from BitShala. Blidbbitd a desktop wallet written in Go, seems able to scan, send and receive. @yashrajd from the Bitcoin.Design community has been working some UX improvements and published its findings here, BitPolito is working on a PoC... What else?1
Dana, that I previously, and today again reviewed, is one of few projects that have adopted been built as PoC for Silent Payments's BIP352 and is looking better and better. That I know, still only other two implementations of the protocol have functional: one being the commercially known Cake Wallet #779074, and Silentium webapp #540780, unfortunately no longer maintained open-source project, such pity.
Cake only run on mainnet and Silenium is still available in both mainnet and testnet, so testing Dana without loss risk has been a bit tricky. Initially, I had to install the app in two different droid phones to silently exchange some sats in Signet.
BitBox was the first hardware wallets (last year in Sept) to implement the send-to silent payments option2. More recently Sparrow desktop wallet implemented the send-to-sp13 too, that's good news. Still, the protocol have a way long way to run. Here are some open bounties available for developers that want to take a challenge:
  • Implement sending to Silent Payment addresses in Sparrow - 0.01 BTC
  • Implement sending to Silent Payment addresses in Samourai - 0.01 BTC
  • Implement sending to Silent Payment addresses in Electrum - 0.01 BTC
  • Implement sending to Silent Payment addresses in BitBox - 0.01 BTC
  • Implement sending to Silent Payment addresses in Foundation Passport - 0.01 BTC
  • Implement sending to Silent Payment addresses in SeedSigner - 0.01 BTC
  • Implement sending to Silent Payment addresses in BDK - 0.011 BTC
As of today, for what I know, the best and most open source way to send and receive bitcoin payments silently is with this setup:
  • BitBox02 as hardware wallet
  • Sparrow wallet for sending BTC silently from desktop
  • Dana wallet to spread the QRcode and sp1address and receive BTC onchain in your mobile
⚠Note: importing your Dana wallet seed into Sparrow will generate a new wallet —the inverse is also true— as by default, the apps are using different oracles. Respectively https://silentpayments.dev/blindbit/signet and https://mempool.space/signet. Make sure the oracle url is the same in both apps
Here's my take for now, if you feel I missed something, leave it in the comments below!

Want to test silent payments?

Give it a try! Here are the faucet for some signet sats4, share your sp1 address in the comments below, and I'll send some sat. Here's mine in case you want to send some back: signet:tsp1qqvlkvumla3gk3ggwcz9kxj04naykcr585l9rhtk45nguy0dyhs49kqe9fn5784fz9lz6g69yud5xuwwjglxwshkta2qua3jr93g03jhsl5py3rkv
While you are trying your preferred tools, think about what you'd expect and compare it with what you experience when using it. Does the two things coincide? Or it could have been different? How?
Share how below, there's still a lot of work to make this protocol more functional and accessible to everyone. Your inputs and feedback helps a lot.

Footnotes

  1. More detailed info available at https://github.com/macgyver13/silent-payments-hub ↩
  2. Check merged issue #1251 https://github.com/BitBoxSwiss/bitbox02-firmware/issues/1251 ↩
  3. Check merged issue #1434 https://github.com/sparrowwallet/sparrow/issues/1434 ↩
  4. will work only when using the oracle https://silentpayments.dev/blindbit/signet ↩
write
preview
related posts
0 sats \ 4 replies \ @Scoresby 13 Oct
Great write up, @deSign_r!
From my understanding, silent payments requires that the user's server is doing a bit more compute. Did you notice this when you were using it on desktop? Or is it the case that using it with sparrow you still needed to connect to a different server for scanning for silent payments?
reply
102 sats \ 3 replies \ @deSign_r OP 13 Oct
yes, true. Sparrow and blindBit both allows entering a birthdate in the wallet settings > advanced. Cake does the same.
The concepts of sync and wallet birthday date or block are new in this "silent" space. Once user set up the birthdate or birthblock in the wallet, it literally takes few minutes to sync: meaning the wallet will check for any transaction with addresses derived from the seed phrase.
If a wallet is new, the birthdate or block should be "now" or maybe few days earlier, and reduce the sync for newly created wallets to few seconds.
If this is not done, by the user or automatically, it could take 1h or more to sync the wallet from block 0. That's why I think builders of such tools should consider defaulting the date or bloc to the nearest creation date possible and let the user change it at user discretion. Adding a notice informing that sync time from this block/date could take more than XXminutes to complete.
reply
33 sats \ 2 replies \ @Scoresby 13 Oct
Once synced, it doesn't have to look at any old blocks, though, right? But, I suppose if the user is only occasionally (couple times a year) the sync might take a few minutes every time they open the wallet. That could be challenging for user experience.
reply
102 sats \ 1 reply \ @deSign_r OP 13 Oct
Yes correct, even if opening once a year I think the sync is fast. And all wallets are displaying a progress bar to inform the user sync is happening, usually with a percentage indicator and in the best cases with a stopwatch.
I feel the most challenging UX is due to first use, more than periodic use. Once user know how the sync works its fine, but when it does not, and the birthdate or block is not set, then it can be annoying. Especially when there's no inform telling the user why the wallet is syncing and how long it could take.
Setting up such input should be by default, or it could also be a learning opportunity for the users as part of the onboarding.
reply
0 sats \ 0 replies \ @Scoresby 13 Oct
Thanks for the good info here. It will be neat yo see how wallets handle it as more roll out support.
reply
0 sats \ 1 reply \ @028559d218 13 Oct
Thank you for your post. Several wallets available for 'sending' the silent payment... not much in the way of receiving however.
reply
0 sats \ 0 replies \ @deSign_r OP 13 Oct
Which other you'd suggest? I focus on those able to do both. I was surprised with blindbit, even if raw and experimental it offers both, and it just works! Available with any network, just need some ~Design work.
reply