Topic: Silent payments (Read 1340 times)

A pull request has been opened for adding Silent Payments to Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/27827

That's the same implementation as in the original spec. Hardly anything has changed since then.

It would be interesting to see a silent payment implementation outside of Bitcoin Core.

https://gist.github.com/w0xlt/a7b498ac1ff14b8c292a22be789bd93f

I know; just wanted to point out that xpub sharing (as alternative to silent payments) is not only less private but also potentially insecure.
Where can I find more information about the latest implementation or proposal? I'm interested to see what the creators think / how they handle SPV wallets and the complexity / burden of scanning for transactions.

As far as I know, this only applies to non-hardened derivation schemes, where it is possible to calculate parent keys by combining chain code with the child's private keys. In the case where the derivation process is hardened, an attacker would need your master private keys to calculate child keys, or parent private key to calculate a child key. All backward derivation won't be possible when derivation is hardened. In the case of silent payments, however, you don't share your xpub at all, replacing it with a deterministically derived silent payment address, which is basically a hash of a public key (not a master public key) encoded in a special format. In the latest implementation, it was proposed that silent payment addresses should start with the "sp1" prefix.

Sharing an xpub is also a security risk, due to being able to derive all private keys from an xpub and a single private key.

How Silent Payments Are Bringing New Privacy Protections To Bitcoin

I think we've got it:
1) "b" is private, but can be non-unique if an address is reused
2) "SHA-256("txid:vout")" is public, but also unique
3) "b*SHA-256("txid:vout")" is private and unique at the same time
And when in the third case we will reach the same value, that would mean double spending of any kind, for example RBF (and it is a nice feature to preserve the same output addresses in case of any transaction replacements).

Nice idea. To make it computationally simple, all that is needed, is using "txid:vout" from the sender's input. That will be always unique, because each coin can be spent only once, so for the same recipient's public key, it will be tweaked in a different way each time.

It can be better than that. We could use z-value instead. Processing transactions is needed anyway, so by using z-value as an offset, it is guaranteed to be unique. And for Taproot addresses, we no longer have SIGHASH_SINGLE bug, so it will always be a hash of some transaction.

Edit: Also, to avoid circular dependencies, the output of the recipient should be cleared during calculating this z-value, so it will be some altered z-value anyway. Or we could put the real recipient key here, then reach this z-value, and then use that to do the tweak in the real transaction.

This can be solved by using R-value of the signature, instead of B-value public key. Then, address reuse would be automatically avoided, because it would mean that two inputs share the same k-value, so if d-values are also identical, this would leak the private key. Each safe wallet will use random k-value, that will be different each time.

The problem is not to have something that cannot be reused.  The problem is to have a means for people to publish information that can be reused to send money to them money, without any other communication between sender and recipient—without the horrific privacy wreckage of Bitcoin address reuse as it now stands.

We already have things that cannot be reused: transactions. It is technically possible to create a signed transaction, where some output is bigger than some input, sign it with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, and then, people can donate just by adding more coins, without invalidating signatures. Actually, this sounds like invoice, and is great when it comes to accumulating dust. The only missing part with such donations is that the creator have to specify the amount upfront, unless it is a donation to some miner, then it can be handled as a transaction fee.

For cryptocurrencies, privacy and fungibility are practically synonymous:  You can’t have either one without the other, and providing either one provides the other.

In practice, a lack of privacy literally means that 1 BTC ≠ 1 BTC.


The most important use case for Silent Payments is tip addresses, donation addresses, etc.  It is a very common and important use case.  This use case has never been solved in Bitcoin; I think that the lack of a solution is a flaw in Bitcoin.  Look around this forum at all the tip addresses in people’s signatures—observe all the donation addresses you see in static webpages.  These all incur the problems of address reuse.  The problem must be solved.

---

Zcash has strictly superior privacy technology, compared to Monero.  In the context of discussing strong privacy for Bitcoin (much stronger than Silent Payments), I addressed similar concerns accordingly:


See Tyler Winklevoss’ above-linked Tweet.  Do you suppose that he would renounce Bitcoin, if Bitcoin were to attain better privacy?

---

My exchange never did that.  (I use DEX.)

For those interested in learning more about silent payments and other similar proposals aimed at improving privacy of on-chain users, you should listen to this podcast:

https://bitcoinmagazine.com/technical/silent-payments-improve-privacy-without-bitcoin-data

"In this episode of “Bitcoin, Explained,” hosts Aaron van Wirdum and Sjors Provoost welcome Ruben Somsen back on the show to talk about his recent proposal for “silent payments.”

Silent payments resemble earlier ideas like “stealth addresses” and “reusable payment codes,” in that they allow users to publish a static address. While this is not the actual bitcoin address where they will be paid, senders of a transaction can use this static address to generate new bitcoin addresses for the recipient, for which the recipient — and only the recipient — can, in turn, generate the corresponding private keys.

Like stealth addresses and reusable payment codes, the benefit of silent payments is that addresses can be posted publicly without harming users’ privacy; snoops cannot link the publicly posted address to the actual bitcoin addresses where the recipient is paid. Meanwhile, unlike stealth addresses and reusable payment codes, silent payments do not require any additional blockchain data — though this does come at a computational cost for the recipient.

The podcast episode details this in roughly two parts. In the first half of the episode, Somsen, van Wirdum and Provoost break down how silent payments work, and in the second half of the episode, they discuss how silent payments compare to stealth addresses and reusable payment codes, as well as some potential implementation issues.

Provoost made a successful silent payment on the Signet Bitcoin testnet, but silent payments are not ready for mainnet use at this time."

I think you are right. Generally to track all incoming payments, you need a master public key from which all other public addresses are deterministically derived. To (re)calculate a particular address, you need two pieces of information, namely your xpub (ypub, zpub) and derivation path to the address. Anyone who has both can reconstruct the address and see all associated transactions. In some cases, one even doesn't need to know a derivation path. In silent payments, you also need only two pieces of information to calculate the address, one of which is a public key of the sender and the other is a private key of either sender or receiver. This requirement (having to have a private key) makes watch-only wallets impossible, let alone the fact that each particular sender creates unique private-public keypair for the receiver, which has no connection with other keypairs.

Hmm. You're not obligated to do a continual real-time scanning to make use of silent payments. Just scan the blockchain once a month, unlocking your wallet for a short time.

Alternatively, we can separate the silent public key into the "scanning key" and "spending key" to mitigate the security risk.

Xpub sharing is a way less efficient way of sharing a series of addresses than silent payments.
In the video, starting at around 33:23 those differences are analysed.

But the summary is: you should share your xpub only with those you are confident sharing your privacy with, as they would be able to track all your received payments scanning the addresses generated from such xpub.
Silent payments instead break this allowing you the total privacy (with the “scanning costs”).

I realized another drawback: the receiver needs their private key to check if they've received a payment. That makes a watch-only wallet impossible, and even if you use Bitcoin Core, private keys are stored encrypted until you enter your password. Keeping the wallet unlocked adds a security risk.

Thanks for the link to a video presentation. When I was writing about silent payments, I couldn't find any visual aids that would help me to understand this technology better. Could you briefly tell us about the advantages of silent payments over the common xpub sharing technique?

I would call silent payments a steganographic method of hiding information because it allows you to get lost in the crowd merely by making completely normal payments with no specific fingerprint. With silent payments you are hiding in plain sight.


It is true, unlike very controversial proposals like covenants, which I personally deem extremely undesirable for bitcoin because they make it less fungible and censorship-resistant, the silent payments technique doesn't require making any changes on a protocol level.

That is possible, but the whole point is that the address is mangled and used just once. That means it wouldn't matter that a specific amount is sent to an addresses - that's the only receive it makes anyway.

I see this as a feature mainly for wallets, not really for websites accepting BTC donations as you can't really make the address update on each load without some PHP or JS running in the backend, and most people won't see a reason to make their addresses that cumbersome.