My First Thoughts on Silent Payments UX \ stacker news ~bitcoin

10.6k sats \ 26 comments \ @Design_r 15 Sep bitcoin

SilentPayments.xyz is a proposed Bitcoin payment protocol under the BIP352 that allows for greatly improved privacy. The system presented herein enables the ability of users to receive payments on a single static paranoia-free reusable address, unloading any extra on-chain overhead by using scripting and cryptographic techniques that also allow much better privacy.

It's a very curious implementation of the initial Stealth Address proposal, it has begun to gain popularity in the Bitcoin community due to its promised simpler, safer UI, and better UX. This obviously means a cost on transparency and providing the user a way to understand what's going on behind the interface. Maybe it still too early and much more need to come to enrich the UX/Ui.

So, I took time to dive a bit deeper on silent payments in the past few days and tested the few apps where has been already implemented:

Dana Wallet (Android only) you can read more on #684460
Silentium.io (Web/PWA) https://app.silentium.dev/
Cake wallet (tested on iPhone, also available on Android and any OS) https://cakewallet.com/ yes I know, is a shitcoin wallet, but if you only add the bitcoin networks it becomes a bitcoin-only wallet ;)

Each app provide a slightly different UX, however, the major blockers I found are:

Scanning the blockchain and the time needed to complete,
Defining the "Wallet Birthdate", a new concept that ins't that intuitive and maybe should be different named or maybe automated somehow,
Transaction speed: as silent payments protocol is directly attached to the blockchain, sometime it take time for transactions to be confirmed
Transaction cost, depend on onchain fees so depending on the season it could be inaccessible or unavailable depending on the transaction amount

In a nutshell, I recognize SilentPayments' potential with its intent of merging the anonymity that Coinjoin today somehow differently provides and the reusability of a single address that has been proposed with PayNym BIP47 currently implemented on Sparrow Wallet.

Yes, ok, from a UX perspective, no interaction between the users is required, and there is no need for more bitcoin transactions than those strictly necessary, directly onchain. However, getting rid of the notification transaction creates an entirely new problem for the recipient that does not know it has received some sats until he check the wallet and scan again the latest blocks.

My intent with this post was to share some thoughts I had when testing these wallets, I'm also interested on your thoughts about silent payments, did you test it somehow or had the opportunity to send some BTC to someone else? How was the experience for you and for the receiver? What do you think is missing in the current UX/Ui and how can we do it better?

view all related items

62 sats \ 2 replies \ @nerd2ninja 15 Sep

I know, is a shitcoin wallet, but if you only add the bitcoin networks it becomes a bitcoin-only wallet

Yes this is what I choose to pick on lol.

No, only adding the Bitcoin network does not make it a Bitcoin only wallet. Here's why:

https://thebitcoinmanual.com/articles/avoid-multicoin-wallets/

The developers don't have a laser focus on Bitcoin (the actual meaning of laser eyes BTW). Because they don't specialize, they are more likely to mis-implement Bitcoin only things or miss entirely certain Bitcoin wallet footguns. A larger codebase also makes it less likely that anyone who isn't a developer for the project has ever and will ever put their eyes on it to review the code.

0 sats \ 0 replies \ @rafael_xmr 16 Sep

I am the cake wallet dev that added silent payments, currently I only work on the Bitcoin features and other misc changes around the app, and the web services, while another dev is focused on evm coins like ETH, SOL and TRX, and another dev is focused on the Monero stuff, etc there's more and we are all able to work together as well

we use common libraries for everything in the code, the bitcoin features are added on top of the https://github.com/mrtnetwork/bitcoin_base dart library which allows more people to have eyes on it since libraries can be reused by any other codebase

pretty easy to do actually, and with this productivity stack this gives us room to have features other wallets don't have (like silent payments) and we can research for more, like paynyms, payjoin, coinjoins, etc, which is what I am doing, I do this while the bitcoin wallet is working and doesn't need to be changing all the time, and the other devs are working on the other stuff, then always moving a few steps ahead

0 sats \ 0 replies \ @Design_r OP 15 Sep

The developers don't have a laser focus on Bitcoin

Being one of the few wallets that has Silent Payments implement does not look like they have lost focus on Bitcoin. It just makes it harder for them to make all their audience happy. From how I see it, it still a non-custodial Bitcoin wallet! Anyhow, there are many easily-accessible functionalities that could bring new users to felt in the shitcoin trap.

31 sats \ 3 replies \ @kruw 15 Sep

In a nutshell, I recognize SilentPayments' potential with its intent of merging the anonymity that Coinjoin today somehow differently provides and the reusability of a single address that has been proposed with PayNym BIP47 currently implemented on Sparrow Wallet.

Silent Payments doesn't have any similarities with coinjoins, it's just a way for the sender to generate a new address for the receiver (non-interactively). BIP352 is a huge improvement over BIP47 for this though.

0 sats \ 2 replies \ @Design_r OP 15 Sep

Yes technically yes, for the end user, that only aim to increase its privacy somehow, it could be comparable. The main issue is that not all users understand to these details the differences between all the BIPs/features.

101 sats \ 1 reply \ @kruw 15 Sep

Yes technically yes, for the end user, that only aim to increase its privacy somehow, it could be comparable.

Silent Payments doesn't increase privacy though, it's just a UX improvement that eliminates (half of) a round of communication between the sender and receiver when a new address is generated. Basically, it's BTCPay Server on steroids.

The main issue is that not all users understand to these details the differences between all the BIPs/features.

This knowledge gap was the huge problem with BIP47 that BIP352 fixes:

BIP47 Paynyms require the sender to have an understanding of how blockchain analysis tactics work, and then manage UTXOs carefully with labels before and after sending multiple on chain transactions.

BIP352 Silent Payments eliminate this clumsiness and the extra on chain fees. The only tradeoff is a heavier scanning requirement.

0 sats \ 0 replies \ @Design_r OP 15 Sep

The only tradeoff is a heavier scanning requirement.

Noted, hopefully there will be some workarounds sometime soon

43 sats \ 1 reply \ @OT 15 Sep

I think it's great for a donation address, although it might be a little late as most people shouldn't want to give small donations on the base layer.

Its good for auto withdrawals from exchanges. Its generating a new address each time without revealing the cold wallets xpub (privacy improvement).

One thing I don't like is the name. It's going to confuse noobs into thinking that it magically makes your KYC'D UTXO private. This is not the case. All the underlying heuristics are still there.

0 sats \ 0 replies \ @Design_r OP 15 Sep

One thing I don't like is the name.

That's a good insight! Thanks for sharing

42 sats \ 1 reply \ @bitalion 15 Sep

Of the points mentioned above, two are related to the chain and I don't think they have anything to do with it directly. A silent payment will be seen on the chain just like another, the magic happens in the wallet of the person who creates the transaction and the person who receives it. Scanning the chain in search of a silent payment must involve an additional load in time, although today those calculations are done in less than a second. The point where you deal with the age of a wallet is the one that I think can be the most complicated, I would have to do a test in cake wallet; but let's say that you have several payments on the chain and then you receive a silent payment, it would be easy in that case; but if the first thing was a silent payment, when should I scan? Here I think the best thing would be to establish a time window, since it is a new functionality, you can define an initial date on which it began to be used and scan from there.

0 sats \ 0 replies \ @Design_r OP 15 Sep

the magic happens in the wallet of the person who creates the transaction and the person who receives it.

You maybe responded to my previous question #685458 with this

the best thing would be to establish a time window, since it is a new functionality, you can define an initial date on which it began to be used and scan from there.

This is a great point to implement some king of automation on the wallets using SP. Thanks

21 sats \ 7 replies \ @south_korea_ln 15 Sep

I think the ones most likely to benefit from this probably don't care about the overhead of having to scan the Blockchain. The advantage here really outweighs the disadvantage. Imagine the Canadian truckers. With this, it would have been much harder to confiscate their donations.

0 sats \ 6 replies \ @OT 15 Sep

Did they actually confiscate Canadian Trucker bitcoin or just threaten them?

It might have been a few more steps more difficult with silent payments. A lot of the KYC'D donations might have also been threatened as they are linked. If the coordinator of the SP wallet consolidated and redistributed it would have revealed all payments.

0 sats \ 5 replies \ @Design_r OP 15 Sep

If the coordinator of the SP wallet consolidated and redistributed it would have revealed all payments.

I don't know, but do you think each Silent Payments coordinator keep track or has access to who does what? Or is the data only stored locally?

21 sats \ 4 replies \ @OT 15 Sep

I just meant for that situation (Canadian Trucker protests). Whoever was collecting donations would be distributing it to the truckers. They would need to be careful not to consolidate. As should any person that has a SP wallet.

0 sats \ 3 replies \ @Design_r OP 15 Sep

Oh ok, I thought you were referring the coordinators to any SP wallets themselves.

190 sats \ 2 replies \ @OT 15 Sep

No, there's no coordinator for SP like in some coin joins. Its all math/software.

0 sats \ 1 reply \ @Design_r OP 15 Sep

That's great to know! So everything reside on the wallet itself?

0 sats \ 0 replies \ @OT 15 Sep

If they're following the BIP, yes.

reply on another page

0 sats \ 1 reply \ @16d86e9daa 15 Sep

Silent payments and privacy-enhancing technologies are crucial for improving the anonymity and security of cryptocurrency transactions. They help address concerns about transaction traceability and user privacy.

21 sats \ 0 replies \ @Design_r OP 16 Sep

0 sats \ 4 replies \ @Rsync25 15 Sep

Interesting points

0 sats \ 3 replies \ @Design_r OP 15 Sep

Thanks, anything particularly?

21 sats \ 2 replies \ @Rsync25 15 Sep

We’re early with SP. We can do better with UI/UX, mainly without need introduce new concepts. I think we can adjust mempool part, where user’s choice fee currently, avoiding major issues as you mentioned above.

0 sats \ 1 reply \ @Design_r OP 15 Sep

we can adjust mempool part, where user’s choice fee currently

I definitely agree, do you mind being more specific? Are you referring to a specific wallet?

0 sats \ 0 replies \ @Rsync25 15 Sep

I’m not referring no one wallet. This idea is a little abstract, I need to think more about this.