Silent payments

[witcher_sense]

I haven't seen any website that shows a new Bitcoin address on each reload, which confirms to me it's not feasible.

I've seen it once, and it was for donations specifically. Can't remember the github.io page. Doesn't BTCPay Server give you a new address each time? Why don't you use that?

https://bitcoinprivacy.me/coinswap-donations

I am not familiar with how BTCPay server works but can't I just attack Alice by pre-generating billions of addresses using her server and tracking all incoming donations? I definitely can't do that with silent payments since I have no private keys of other donations.

[LoyceV]

But what if I send a very specific amount. Then I could just look at the next block, find that amount and see to which address it is send in reality. So at least the sender can very easily verify the real address.

No need for that: the sender already knows the real address. It's not possible to send Bitcoins any other way.

[BlackHatCoiner]

https://bitcoinprivacy.me/coinswap-donations

Yes! That was it.

but can't I just attack Alice by pre-generating billions of addresses using her server and tracking all incoming donations?

You can't track her donations, because the address you will generate won't be shown to anyone else. Once an address is shown, it's never used again. You can of course attack her by generating billions of addresses, but that will only increase her children, and, therefore, make her monitoring more difficult. It's a similar problem to DDoS.

[n0nce]

Yes, this is exactly what sprung to mind when I read this proposal. In my opinion, the biggest disadvantage - just as in Monero - is the need for transaction scanning.

There were around 100 million Bitcoin transactions in 2021 [1], while Monero only had around 5 million transactions in the same time [2] - a factor of 20 that is not insignificant I'd say, especially when using an SPV wallet. If you open it after a few weeks or months of inactivity, it will have to churn through a ton of computation if such a scheme was introduced in Bitcoin.

That's easy to prevent: don't add Silent payments to SPV wallets. If you want to use this, run your own full node, and keep it online. You'll download everything anyway, and only have to check a few transactions per second. That shouldn't give any problems. And it's better for privacy.

What if you have billions of page loads? For a site such as TPB, that's very well possible and it means they have to monitor billions of addresses. Even if you don't monitor them continuously, you'll have to regularly check for donations. I haven't seen any website that shows a new Bitcoin address on each reload, which confirms to me it's not feasible.
With Silent payments, you only have to monitor a few transactions per second.

That's a good point. Especially since you need to run a full node anyway when using a current implementation of what's described here (such as BTCPay Server). In this case, it's required to scan all derivation paths - up until the 'last generated address' - forever, since someone could get a new generated address from your site, save it and donate money to it a few months or years later. It can be 'attacked' by making the software generate thousands or millions of addresses, so you'll need to continuously scan for m/84'/0'/0'/0/1 to m/84'/0'/0'/0/918231812 from that point on, for example.
Though that's exactly what you're doing with silent payments as well, right. Check a few transactions per second (a few thousand per 10-minute interval) and match against all possible derivation paths based on your seed / public key, pretty much.

But what if I send a very specific amount. Then I could just look at the next block, find that amount and see to which address it is send in reality. So at least the sender can very easily verify the real address.

Besides the sender knowing the real address, since that's where they send their money; in Monero, the sent amount is encrypted and you can only observe from the outside that input and output amounts match. I'm not sure if the silent payments proposal includes something like this, but I'm pretty sure it doesn't.


All in all, it seems to me like this silent payment proposal is basically just going to move this 'feature' from application level (BTCPay) down directly into the protocol level. Since it doesn't change the requirements or effects compared to the current application level implementations (full node, always on, scanning basically just as much), I currently don't really see the need of it. Without need of blockchain scanning, it would be a nice addition for people who want to receive donations and don't (want to / can) run a node.

Generally, I believe it's universally accepted that keeping the 'base layer' compact and simple is better, unless it's absolutely needed. For instance, SegWit allowed to build Lightning and had many more new advantages, but it was a relatively compact change and it didn't change more than what was absolutely needed. Or also Taproot, which allows to do new things that weren't possible before (opposed to moving existing functionality to the base layer).

[fillippone]

I am popping in to share an article that was published by Bitcoin Magazine, that can help the less technical of us to grasp the basics of the topic discussed here.

IMPROVING BITCOIN PRIVACY WITH SILENT PAYMENTS

The article is very basic and originates from Marty Bent's newsletter, but they claim they will update it when more details emerge.

Another "not too technical" resource is the following one:



Where I got a very clear overview of this technique. And solved my first thought about this (why it is superior to "xpub-sharing")


Just a couple of things that caught my attention:

The irony is strong with this one:


The second reflection revolves also around the BIP119 drama. Silent Payments are techniques which don't require any new functions in the bitcoin protocol. It's a very elegant and effective technique to gain privacy from transactions and solve a real problem. What I mean, so much remains to be "discovered" using the current bitcoin protocol, we cannot risk anything implementing a new feature which is secure and scrutinised beyond any reasonable doubt.

[NotATether]

The payment will not be traceable.

Let's say TPB accept Silent payments. Someone sends them a donation, which confirms on-chain. Nobody else can know TPB is the receiver, because they can't know which on-chain address belongs to their Silent payment.

But what if I send a very specific amount. Then I could just look at the next block, find that amount and see to which address it is send in reality. So at least the sender can very easily verify the real address.

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.

[witcher_sense]

Another "not too technical" resource is the following one:

https://rumble.com/v12kuz7-bitcoin-silent-payments.html

Where I got a very clear overview of this technique. And solved my first thought about this (why it is superior to "xpub-sharing")

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?

The irony is strong with this one:

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.

The second reflection revolves also around the BIP119 drama. Silent Payments are techniques which don't require any new functions in the bitcoin protocol. It's a very elegant and effective technique to gain privacy from transactions and solve a real problem. What I mean, so much remains to be "discovered" using the current bitcoin protocol, we cannot risk anything implementing a new feature which is secure and scrutinised beyond any reasonable doubt.

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.

[LoyceV]

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.

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.

[fillippone]

Could you briefly tell us about the advantages of silent payments over the common xpub sharing technique?

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”).

[witcher_sense]

I realized another drawback: the receiver needs their private key to know they've received a payment. That makes a watch-only wallet impossible,

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.

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.

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.

We can extend the silent payment address with a scanning key, which allows for separation of detecting and spending payments. We redefine the silent payment address as the concatenation of X_scan, X_spend, and derivation becomes X' = hash(i*X_scan)*G + X_spend. This allows your internet-connected node to hold the private key of X_scan to detect incoming payments, while your hardware wallet controls X_spend to make payments. If X_scan is compromised, privacy is lost, but your funds are not.

[witcher_sense]

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

[death_wish]

7) Silent payments greatly improve the fungibility of bitcoin transactions.

...
You were probably referring to privacy.

Privacy and fungibility are directly related because bitcoins can be discriminated by address and addresses can be associated with people, but I agree that "privacy" is more appropriate.

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.

Anyway, I don't think that this payment method greatly improves privacy because it only removes the need for the receiver to communicate with the sender. If communication is already private, then nothing is gained.

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.

It looks like btc will go closer to what Monero was am I right? The problem I see with that is Monero was limited in growth because of the mass bans probably because of KYC. If Bitcoin implements silent payments to increase privacy (Woo!) would this put us at risk of meeting the same fate as Monero? or are we too big?

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:

Feel like BTC has walked that tightrope pretty well......

Not to discuss altcoins in WO, but as raw data for contemplating the hypothetical of a Bitcoin with strong privacy:  Gemini supports Zcash shielded withdrawals.  That is a NY Bitlicensed, notoriously ultra-KYC exchange, under one of the most onerous regulatory regimes in the world.  They started support for shielded withdrawals, after Zcash was hit with some high-profile exchange delistings during a FUDstorm; Tyler Winklevoss made Gemini’s position quite clear.  The Rock Trading in Europe is another regulated KYC exchange that supports Zcash shielded.

The exchanges have users’ KYC dox.  Police, tax enforcers, et al. can tell targeted persons, “Give us your view keys, or else”; view keys permit viewing, but not spending of shielded money that is otherwise entirely invisible on the blockchain.  Gemini or The Rock Trading users who withdraw shielded Zcash are concealing their private finances from the world; they will not end up on any “rich lists”, their finances are protected from snooping by cyberstalkers, and they can sleep quietly at night without worrying about armed robbers.  But they are not in any position to hide from their governments.  This issue is not as simple as it seems at a glance.

I think that Zcash has walked that tightrope pretty well.  Bitcoin could have done similarly—and it could do similarly, in the future.

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

Try it, use a mixer for your bitcoins and sell them on some exchange. Lots of exchanges blacklist bitcoins from mixers.

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

[vjudeu]

These all incur the problems of address reuse.  The problem must be solved.

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.

[death_wish]

These all incur the problems of address reuse.  The problem must be solved.

We already have things that cannot be reused: transactions.

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.

[garlonicon]

Sender's potential for address reuse.

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.

[vjudeu]

This can be solved by using R-value of the signature, instead of B-value public key.

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.

[garlonicon]

We could use z-value instead.

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.

[vjudeu]

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

[witcher_sense]

How Silent Payments Are Bringing New Privacy Protections To Bitcoin

[n0nce]

Could you briefly tell us about the advantages of silent payments over the common xpub sharing technique?

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”).

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.

If, and only if, the recipient also obtains a single private key from your wallet, the recipient can obtain all your private keys and steal your funds, just as if they had your xprv key.