pull down to refresh

Say hello to silentpayments.xyz

Wanting to learn more about Silent Payments, see which wallets support them, or find out how to integrate them into your wallet?

I've built out a website with all of that info and more to do what I can to speed up Silent Payments adoption.

sounds very interesting, haven't deep dived so far, but what happens if the sender does not derive new addresses and sends it to the same address over and over again?

reply

It's impossible for the sender to do so, as the output address is derived deterministically from the senders input pubkeys.

It literally makes address reuse technologically impossible :D

reply

great that answers my question, tank you! and sorry, I was to lazy to run through the docs, where I would have likely found the answer on my own :D

reply
No server required
Silent Payments remove the need for complicated infrastructure to handle donations and payments privately. Simply post a static address and call it a day.

I thought the receiver had to scan all transactions/UTXOs since they created the wallet to figure out if they received something?

reply

That's true. From the website

Tradeoffs
Because Bob cannot pre-generate addresses with silent payments, he needs to keep checking to find new payments from the point he generated the payment code. Because this scanning is relatively costly, Silent Payments require more compute and bandwidth when scanning than a standard Electrum-style server. The average Bitcoin wallet today will have to connect to a new type of server that serves the necessary “tweak” data for a wallet to check each potential transaction for themselves.
The key difference with Silent Payment scanning is that instead of pre-generating a large amount of addresses up front like with a standard BIP 32 light client, Silent Payments requires the wallet to download 33 bytes of data per potential output and then perform an ECDH calculation to check if it is owned by the user. The major benefit to this approach is that it provides excellent privacy (even for light wallets) as the wallet back-end does not know what outputs belong to any light client.
Even though this may sound like a major hit to user experience, thankfully we can already drastically improve sync performance by ruling out potential outputs like:
Non-Taproot outputs
Taproot dust outputs <=1000sats (~85% of > Taproot outputs right now)
All potential Silent Payments outputs spent since you last scanned
Additionally, there are many brilliant people working on reducing the impact of this tradeoff through things like transaction cut-through, Silent Payments-specific indexes in Bitcoin Core, and much more.
reply

Yes, found that later.

Overselling duly noted.

reply

Yeah, although Ruben Somsen usually does not oversell it when he talks about this invention of his. He acknowledges this limitation. Yet, this increase in bandwidth or computation time is probably not a concern for someone who really needs to keep his payments silent ;)

PR styles differ...

reply

I can imagine Ruben would keep it real.

Classic @sethforprivacy setting up people to become disappointed with Bitcoin and switch to Monero. /jk ;D Very nice work overall, except for the server salesmanship.

reply

The difference is that you don't need separate infra just to generate new addresses for every user, but of course you still need a back-end to sync your wallet, just like any other Bitcoin wallet.

In the future this will likely just be an extension of Fulcrum/Electrum as there are already forks that add Silent Payment sync to these in a privacy-preserving way, meaning a Silent Payments user could sync using a public remote node without sacrificing privacy, thus requiring no infra.

reply

Could you explain to this noob what is meant by generating infinite addresses based on one static address?

Is my stacker Lightning address considered a static address?

reply

Yes, think LN address but for on-chain, and without requiring extra infrastructure unlike LN addresses.

I just give you my SP address:

sp1qqweplq6ylpfrzuq6hfznzmv28djsraupudz0s0dclyt8erh70pgwxqkz2ydatksrdzf770umsntsmcjp4kcz7jqu03jeszh0gdmpjzmrf5u4zh0c

You scan it via QR or copy-paste into your favorite wallet, and on-chain you are sending to a new, unique, one-time address every time. No "send me a new address please!" hassle, no need for the receiver to keep cycling addresses, etc.

reply

Yes, I want to learn. Thanks for sharing link.

reply
reply

If it really enhances privacy, it's good. We also need some sort simplicity while publicizing it. We should also and always consider non-tech folks as well.

reply

Good stuff. I think. Will need to spend some more time exploring this.

Privacy is only going to become more important going forward, so I appreciate all the effort that's going into improving it - even though it's hard to keep up with everything happening.

reply

Thanks for sharing Seth.

reply

What is the main difference compared to paynym (bip47) ?

reply
reply

Amazing site. I didn't even get that far yet...

reply

No rush at all :)

So glad it's been helpful already!

reply

Is this a BIP ?

reply

Yes, BIP 352: bips.dev/352

reply
10 sats \ 1 reply \ @ca 18 May 2024

How is it possible that wallets are already implementing it if it's not part of the Bitcoin protocol yet? Can you explain that part?

reply

This is not a change to the bitcoin protocol. Instead it is a protocol used by wallets to derive one time addresses to send to from a static address.

reply

If it really works it would simplify things a lot

reply

It really works, have already been using on mainnet ;)

reply
10 sats \ 1 reply \ @OT 17 May 2024

What does the onchain TX look like? Would it be visible by the amount sent?

reply

It just looks like any other on-chain Taproot payment, there is nothing distinctive on-chain that makes it stand out as having used a Silent Payment address.

reply

Hey Seth, ive noticed that cake wallet doesnt work with electrs servers that are self hosted over tor. would be an important addition, ya? if one were to want improved privacy with the silent payment scheme.