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.
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
nice
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
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
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
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
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
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
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
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
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.