Bitcoin Forum

Introduction

In this thread, I would like to discuss an interesting proposal by Ruben Somsen called "Silent payments," which is a privacy-improving technique aimed at making payments between two parties on the blockchain less transparent for an outside observer. It is based on such concepts as "stealth addresses" and "reusable payment codes" and essentially is trying to solve the same problem but in a more elegant way.

The basic idea

The basic idea is the following: user A publishes some identifier (usually a public key), and user B combines his private key with the published key of A and creates a unique address from which only A can spend. User C can also send money to user A by combining his private key with an address of A and deriving another unique address. User A will know that both users B and C sent him money, but B and C won't know about each other. Therefore, that allows user A to receive payments on completely delinked addresses using only one public address.

How it works

Say Bob wants to send a silent payment to Alice.

1) Alice creates a unique identifier (say, a public key) using standard elliptic curve mathematics:

 A = a*G, where

A - Alice's public key (a point on an elliptic curve),
a - Alice's private key (a random number which should be kept in secret), and
G - the generator point (some pre-defined point on an elliptic curve).

2) Alice makes this identifier A public so that Bob (and also other users such as Carol) can know where to send payments.

3) Bob chooses one of the inputs he controls which contains a public key

B = b*G, where

B - Bob's public key (a point on an elliptic curve),
b - Bob's private key (a random integer which only Bob knows), and
G - the generator point.

4) Bob takes Alice's public key A and constructs a new public key using the following formula:

A' = hash(b*A)*G + A, where

A' - a public key to which Bob's payment is made.

5) Bob makes a payment to Alice creating an output associated with a previously constructed public key A'.

6) Given that b*A = b*a*G = a*b*G = a*B, Alice can reconstruct the same public key A' using her private key a with the following formula:

A' = (hash(a*B) + a)*G, where

hash(a*B) + a - Alice's new private key which allows her to spend money from the output corresponding to public key A'.

However, the problem is Alice needs to know Bob's public key B to detect her payment, which is why she continually scans the blockchain trying to figure out which of the public keys can be combined with her private key a to reconstruct existing bitcoin addresses.


Pros:

1) No interaction between senders and receivers is needed. For a sender to make a payment, he only needs to construct one address from the receiver's silent public key.

2) Silent payments use blockspace more efficiently since there is no need for any "announcement" transactions, as in the case of BIP47. Therefore, one transaction equals one payment, which is perfect for one-time donations

3) Silent transactions are indistinguishable from regular transactions (e.g. no OP_RETURN outputs to share an ephemeral public key as in the case of "Stealth addresses"), which means with them, it is trivial for users to hide in the crowd - the anonymity set is the whole blockchain.

4) Addresses derived from the initial silent public key are always deterministic and unique because each sender uses his own unique keys to tweak the receiver's silent public key.

5) Silent payments incentivize a receiver of funds to keep their own Bitcoin full node running, which automatically results in a more decentralized network.

6) No one, except for the sender of the transaction and its receiver, will know that the payment actually occurred.

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

Cons:

1) The biggest disadvantage of this technique is the relatively high validation cost. Given that a recipient of payments doesn't know in advance which bitcoin addresses can be spent with a private key he controls, he has to check each input of each transaction, calculating and comparing public keys.

2) Sender's potential for address reuse. When a sender has multiple inputs sharing the same public key, each of these inputs will result in the same calculated address. Reusing the address is considered bad privacy practice and should be avoided at all costs. This could be mitigated by including additional information into the computational process, but creates an additional burden, especially for light clients. Alternatively, a sender can spend all inputs in a single transaction, but this also reveals common ownership, which damages privacy.


References:

1] https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8
2] https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki
3] https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
4] https://en.m.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman
5] https://bitcoinops.org/en/newsletters/2022/04/06/
6] https://bitcoinmagazine.com/technical/bitcoin-silent-payments-secret-keys
7] https://bitcoinmagazine.com/technical/improving-bitcoin-privacy-with-silent-payments
8] https://gist.github.com/w0xlt/72390ded95dd797594f80baba5d2e6ee

Your schema remember me what in Monero is called Stealth Addresses:

Maybe this can be useful to compare the ideas:
https://www.getmonero.org/library/MoneroAddressesCheatsheet20201206.pdf

After reading it a few times, I think I'm starting to understand it. I would add another Con: something very simple suddenly becomes very complicated.

There are differences between public key and address while referring to bitcoin. In the proposal, public key is referred to as address which would be very confusing because public key is different from address. Although, I get the fact that this type of payment is completely different from onchain payment.

The recipient publishes their silent payment address, a single 32 byte public key: X = x*G (https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8)

It would be quite worth it to discuss more about this, I scanned through the proposal on GitHub but I did not see anything like incentivizing a receiver running node.

To be sincere, the process is kind of complicated and not supporting BIP32 HD keys which even BIP44, 49, 84 and 86 are using its path for HD key generation. I mean which defines HD wallet.

How is this a benefit, according to the proposal?


Which makes address reuse prevention not to be possible and also not favoring light clients. A complicated process that will enhance address reuse should not be recommended like you also commented, it is really a disadvantage.

Never mind my questions, I will also like to know more about fee in relation to silent payment? Having no fee? Or this may lead to more discussion.

Even while using lightning network, onchain transactions are used to open and close a channel and yet the bitcoin would be credited to an address generated by standardized derivation path which this proposal do not include and yet indicating not including the derivation path as a benefit.

Likely, some address types will not be supported which has not happened before.

This is just my opinion, I may not be totally right, but if I am corrected.

I have an idea to somewhat reduce the cost of scanning transactions:

We know that a spending transaction will automatically reveal the sender's public key (in the DER signature area). Each block has on average 10K-20K transactions nowadays (sometimes upwards to 50K). That automatically assumes 50K validations required, which will increase if a transaction has multiple outputs.

In the case of Bitcoin Core, the validation can be multi-threaded if so desired to save time. An additional thread can scan the incoming block to harvest public keys from transactions, and save this to an additional file (perhaps a BDB called pubkeys.dat.xxxx). This will make block validation & wallet balance scanning on startup much quicker as block data doesn't need to be parsed again.

In such a way, we not only have a cache of pubkeys, we can also speed up the silent key scanning process if we so wanted.

Some pseudo [because I don't know libsecp256k1 semantics] C++ that could form the nucleus of validation is given below.

They don't, because there is not such thing as fungibility. It's a made up nonsense. One coin is, and should be equal with any other. Period. The only ones who disagree with this principle are exchanges that cooperate with surveillance companies, and which enforce completely arbitrary rules. They blacklist coins that are either CoinJoined, PayJoined or come from a mixer. It won't surprise me if they asked to provide further info because of "input silence".

You were probably referring to privacy.

That's literally what fungibility means ;) Bitcoin is fungible. You could argue it's not possible to "improve fungibility" because it's perfect already. But some people talk about "dirty Bitcoin", which means they don't think all Bitcoins are equal:
It's like complaining to a bank that the banknotes you received were previously used in a crime. It doesn't matter.

Yep, that was my point.

I don't think there's a reason to put this verb next to it. Something is either fungible or it isn't. You can't have it both ways.

Even worse. The bank rejects your deposit and requires personal info to... Verify you're an idiot?  :P

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.

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.

Once you get yourself familiar with how Elliptic-curve Diffie–Hellman key exchange scheme works, it becomes much easier to understand the idea of silent payments and other similar cryptographic privacy-enhancing methods of obscuring transaction processes in the bitcoin network. In a nutshell, all bitcoin users, who practice self-custody of their coins and therefore have direct access to private-public keypairs, can create a shared secret between each other using Diffie–Hellman algorithm. Alice and Bob exchange their public keys, multiply the new public key by the private key they control (elliptic curve multiplication, not an ordinary one), and use this new value in some function they both know about. In the case of silent payments, they create a new public key to which only one party will have a private key.


This part is indeed confusing. I think when they say "payment address," they mean a public key encoded in a specific format to be distinguishable from regular non-silent public key.

Your primary "silent public key" can be derived using standard derivation scheme, whereas all derived silent payments addresses constructed by senders will have a strong mathematical relationship with your public address and therefore are always deterministic. If you lose your private or public key, you can calculate them using your main seed, and than search again to find all connected silent addresses.

That's a lot to ask, and I don't expect 99% of the Bitcoin users to ever fully understand it.

I can have a general idea, but I don't have the illusion I'll ever fully understand all the details of cryptography. And I think that's okay, we don't need to fully understand it to be able to use it.
My layman summary: Silent payments allow me to post an "address" on a public website, and someone can pay me without anyone else knowing they paid me. If that's correct, this is brilliant!

That is correct, but remember, it *only* works if the address is received from exactly once (and is marked as "spend immediately in the next transaction").

Otherwise, it just becomes a fancy method of generating a single, normal, address from a privkey, nothing else.

Exactly. Consider the following possible use case where silent payments may be very helpful. Say, you're applying for a signature campaign or for some other paid activity where many participants are involved whom you don't trust. In the job application, you specify your silent pseudonym instead of a static bitcoin address accessible to literally everyone who can read. Other participants do exactly the same because they don't want others spying on their financial affairs. The employer makes a list of approved silent pseudonyms, imports this in his private bitcoin wallet, and generates corresponding "real" addresses when it is due time to pay. Each time his wallet makes a payment, it adds multiple unique parameters (txid, index, timestamp, etc) into the address construction process in order to prevent address reuse. If you work for ten weeks, you will end up with ten unique addresses completely unrelated to your initial pseudonym or your other addresses. Even if the employer makes his payment transactions public, it will be impossible for an outside observer to determine which coins belong to which pseudonym. In this case, even employees themselves cannot map transactions with pseudonyms due to equal amounts of some transactions. Only the employer (campaign manager) will know to whom he sent a payment, when, and how much, but he should have access to this information anyway.


Could you elaborate on that?

Does it imply if there are multiple transaction on the address even when the sender and receiver alone knows about the transaction there is still no privacy? I was thinking if no one else knows about the transaction since it's silent payment then a strong privacy is established. I will like to know more about the "fancy method of generating a single, normal, address from a privkey, nothing else."

Great Article mate, while more I read more it makes me think about monero... I remember the 'Fungibility' term in the Mastering Monero book, and I would like to quote that section, because that's the way they worked around the 'Silent Payments':


About this point:


I like the logic behind the 'Silent payments', but thinking about how the bitcoin blockchain should work with this idea makes my mind blows up.

Bitcoin blockchain was made to be public information, if we start obfuscating transactions then the community will divide, and then the fork will come. That's why I think these silent payments should be focused on a new coin and not be implemented in bitcoin.

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?

Don't worry about that. The exchanges could only afford to ban Monero because of it's small market cap. If they were to put a similar ban on BTC then they would have to liquidate their BTC holdings [which represent most of their reserves] and most of them would go under. :)

The bitcoin community has never lived in harmony: there have always been disagreements regarding different aspects of bitcoin, namely how bitcoin should work: block size war, what bitcoin should be: a store of value or medium of exchange, and what is more important: adoption at all costs by flirting with governments and corrupt banksters or self-sovereignty of individual users who value being free and independent. There have always been compliant and non-compliant people; there have always been people who understand the importance of privacy and who don't care because "they have nothing to hide"; there have always been people who despise KYC/AML useless regulations and who readily give up everything to gain a small yield. This community has many faces merely because bitcoin is for enemies and friends, for villains and heroes; it's for everyone because it doesn't judge.

As for silent payments, they won't make blockchain less transparent; blockchain will remain public, open, and accessible for everyone to subjectively interpret transactions occurring inside it. Let us not confuse "transparency and openness" with "KYCed transactions" where the identities of both the sender and receiver are known to the world. If the privacy of transactions is compromised by attaching KYC information of participants, bitcoin can no longer be a censorship-resistant and decentralized network. These things simply can't work without one another.  Silent payments may help users protect their right to privacy, which is the right to "selectively reveal yourself to the world."

Why? From the blockchain's perspective, nothing changes. It will just show a transaction from address A to address B, and it doesn't matter how the owner of address B gave their address to the owner of address A.

I do not think any exchange can decide not to accept bitcoin because it will have side effect on the exchange, it is true that the transparent bitcoin blockchain helps in adoption but exchanges can decide to accept only on-chain transactions if they want transparency. Even, in a lightning network payment, only what is most transparent is when opening and closing a channel, lightning payment transaction is not also recorded on blockchain.



But silent payment will not be transparent as it is not even existing on blockchain at all and the public will not know about the transaction. The payment will not be traceable.

If this can be like a layer 2, it will be better, in a way there will be a bridge between silent payment and on-chain transaction just like lightning network.

As far as I understand, this is incorrect.

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.

I don't think this helps: when opening a LN channel, there's no need to publish your address publicly.

Apparently, you misunderstood the concept. The silent payment is an on-chain transaction like any other: it exists, is written into the blockchain, and is visible to everyone who has a copy of blockchain data. It doesn't hide the fact of payment: it hides the fact that a certain address in the blockchain was derived from the "silent" address you made public. The sender will know that this new address belongs to you because he used your data to generate it. The receiver will know this new address belongs to him because he scans the blockchain for all addresses he can spend. Others will not know this new address is yours because they can't know a secret that was used to create this new address. However, others can generate their own addresses by modifying the "silent" address you made public. Each of these transactions will be broadcast to the network and written into the blockchain.

You are right, I misunderstood what silent payment is, I thought the transaction will not be available on blockchain, but not like that, it will be available on the blockchain.

So far the transaction is available on blockchain and transparent to the public but in a way the recipient can not be known (or linked to the identity of the recipient), then this (layer 2) is not needed.

The intent of Silent Payments is to minimize address reuse by not requiring to communicate a new address for every transaction. Instead, it allows the party to generate a new address for the other party without interaction. It's basically a non-interactive counterparty address generation, similar to stealth addresses. This is just an overview without implementation details. In theory, if nobody reused addresses, it would not bring any privacy benefits, but in practice a lot of people reuse them. Something to note is that it is in the interest of both parties to not reuse the address. In a transaction, the sender will, most of the time, automatically generate a new address for his/her change output, but if the receiver address is reused, then you know which output is the change output which brings down the privacy not only for the receiver because they reused the address, but for the sender as well because everyone knows which is the change output.

what if the silent payment gets intercepted by a middle man through "Man in the middle attack" whereby Alice' public key was changed by the attacker to his own public key then sends to Bob and in similar way, Bob's public key gets changed by the attacker and forwards his own public key to Alice instead, so can he control the transaction in his favor and compute the both public keys with his private key? And what are the ways to bypass such attack when using silent payment?

If Alice and Bob communicate through a secure transfer protocol, such as with SSL certificates, then MITM attack becomes more difficult to execute. And they should, with or without silent payments. Otherwise, their internet provider and the server they use to communicate can de-anonymize them.

So why they don't just generate a brand new address in each refresh, for each visitor?

If an attacker can change public keys, he can steal funds instead of monitor the transaction. That's the same result as an attacker who changes the Bitcoin address.

I was thinking the same thing. Maybe because creating a new address for each visitor means they have generate and monitor millions of addresses.

You are right if any exchange did get rid of Bitcoin because of silent payments being implemented they would be giving up >50% of their revenue. Exchanges know that altcoins are generating them money only temporary but the long term is Bitcoin. If governments start requiring exchanges to ban any cryptocurrency with privacy features then P2P exchanges will become more prominent and if you ask me I think that will be a good thing because it encourages privacy and usually means people are not going to be using the web wallets on exchanges.

Yes, but I guess what @oryhp says is that if you communicate without a secure connection you can't be sure there isn't someone spying on you without you knowing it. Sure, he can take the money, but what's more valuable? Depends on your threat model.  :P

You only need to derive millions of addresses from one master public key, and save those with a balance.

I was assuming a secure connection. Nothing works if you don't exchange the receiver address securely... silent payments are slightly better in the sense that they require a single secure exchange as opposed to having a secure exchange for every receiver address. Securing connections shouldn't be that hard today.

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.


Interestingly, Lightning did start to get adopted by a handful of exchanges lately. So I don't see more Bitcoin-native privacy solutions as a future problem for exchanges. However, my stance towards centralized exchanges^{[pretty negative]} is not a secret around here, anyway. So I'd take more on-chain privacy, regardless of what exchanges think about it, as long as it's otherwise a good improvement.

That's correct: this is just a way to give someone your address without the need of a private channel. And to allow posting a public key somewhere static, but getting paid into different 'actual addresses' (in terms of private keys needed to spend those UTXOs).

They absolutely could. This is just a way to allow people to post something static online, without need to generate one per visitor or site reload. As said before, it also removes the need for a secure channel since anyone can intercept this published address, in-flight or wherever, because the sender doesn't use it directly, but combines it with his own key.

Sure, a MITM can change Alice's public key in transit; but this is a point for a system such as in monero, because the public key can literally be posted on your website or Bitcoin profile publicly. This way you could use multiple devices and internet connections (less likely to all be compromised by the same attacker) to verify that they match.
I lost you at 'Bob's public key gets changed by the attacker and forwards his own public key to Alice instead, so can he control the transaction in his favor and compute the both public keys with his private key'. How exactly is this supposed to work? Could you explain more in detail maybe? In the scheme described here, Bob's key is actually never sent back to Alice in the first place.

[1] https://blockchair.com/bitcoin/charts/total-transaction-count
[2] https://web.getmonero.org/2021/04/24/this-year-in-monero.html

An attacker can inject clipboard malware into Bob's computer and trick Bob to sending payment to an attacker instead of Alice. Silent payments don't provide any protection in this regard. Therefore, to avoid such an attack, Bob should check the authenticity of Alice's silent public key before making a payment. An attacker intercepting Bob's public key achieves nothing because he can't use this information to reconstruct a shared secret between Alice and Bob. The only way an attacker can spend coins sent to Alice by Bob is by stealing Alice's private key. Alternatively, an attacker can still Bob's private key and send coins to the address he has control over. In both cases, an attacker needs a private key of either Alice or Bob for an attack to succeed. Consequently, a silent payment transaction is as safe as any other bitcoin transaction.

Quoting part of the OP:
Isn't this already happening? Well, not exactly with one public address, but with one master public key. You can create nearly unlimited addresses which aren't linked and there's neither interaction from the sender.

I still don't understand how silent payments improve anonymity. Doesn't Alice still have lots of outputs in different addresses? Didn't she have the same problem before?

Anyone who has your extended public key can see all your transactions, anyone who has your silent public key sees literally nothing. That is the difference.

Previously, Alice had one address with many outputs created by different senders, with silent payments Alice has many addresses, each of which with just one output (provided that it is an ideal implementation that prevents address reuse). In the former case, all outputs are linked, in the latter they are completely delinked.

I was thinking the same. If Bob can communicate with Alice using her original address, she can send him one of her newly generated addresses and he can send funds to that new address. Silent payments are not needed if they can communicate between each other. Advantage of silent payment would be if Alice receives many payments and cannot reply to senders.

It would be more interesting to hide sender, not receiver. Maybe silent payments together with help of miners can break connection with senders. Let's say we added a rule to Bitcoin that when a sender sends 1 coin to some kind of null address then miner will include that transaction plus new type of transaction without inputs (similar to coinbase transaction) that pays back 1 coin to new silent payment address of the sender that only miner knows. We are assuming that miner will not reveal that information. In case miner cheated and sends coin to somewhere else, the sender probably can raise an alert(I have not thought of all the math) and honest nodes will reject that block. If lots of senders participate it will work like a mixer.

Sure, but you're supposed to hide it, just as you hide your private keys. And if you don't trust your web hosting service, which is normal, you can make it contact with your home's server. Such as Pi <--> Web hosting' server <--> Sender

Either way, you need to run your own node and scan for every transaction.

No, I mean the idea with the master public key. No address reuse.

Let me show you.


The result is the same. Alice has received donations in several addresses, that have no connection.

She doesn't have to reply to anybody. Address generation can happen automatically.

Use a mixer then, end of story. No need to complicate it with miners and coinbase transactions.

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

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.

This would break the very basics of a blockchain. It's literally in the name: a chain that shouldn't be broken.

No. Just no. Let's not give the sender of a Bitcoin transaction the power to orphan blocks.

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.

Then don't do business with people who treat bitcoin as non-fungible.

You don't have to generate a new address for each page load. Just have a "Donation here!" link; whoever wants to donate will click it. Definitely not billions, not even hundreds of thousands.

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?

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.

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.

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

Yes! That was it.

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.

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.

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

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 (https://bitcoinmagazine.com/technical/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:

https://i.ibb.co/F5jmxTm/60289228.png (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")


Just a couple of things that caught my attention:

The irony is strong with this one:
https://i.ibb.co/dGLq50C/60289228.png (https://twitter.com/SomsenRuben/status/1529377814738247681?s=20&t=oJYnviWHIVQ7QwqN7d6FIA)

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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

How Silent Payments Are Bringing New Privacy Protections To Bitcoin (https://bitcoinmagazine.com/technical/silent-payments-make-bitcoin-more-private)

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.

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.

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.

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

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.

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

Considering the current developments being made - namely the BIP352[1] issue tracker[2] - I figured it would be interesting to (re)kindle the discussion. To add to the explanation provided by witcher_sense, this[3] website also provides a considerable amount of information that allows someone that is out of the scope to also understand what silent payments are. Some proof of concepts are being developed[4] - open source[5] - so it will be interesting to see where this goes from here especially regarding adoption for the use cases provided.

---

[1]https://bips.dev/352/ (https://bips.dev/352/)
[2]https://github.com/bitcoin/bitcoin/issues/28536 (https://github.com/bitcoin/bitcoin/issues/28536)
[3]https://silentpayments.xyz (https://silentpayments.xyz)
[4]https://app.silentium.dev/ (https://app.silentium.dev/)
[5]https://github.com/louisinger/silentium (https://github.com/louisinger/silentium)

Correct. Discussions about Silent Payment like this need to be revived even though I just found out about Silent Payment and this topic is only today I know. With active discussion

Not waiting long after reading the topic of dkbit98 entitled Wallets Supporting Silent Payments (https://bitcointalk.org/index.php?topic=5496774.0), I tried at Silentium Wallet. The process to get a silent payment address is very easy and I already have a silent payment address.
Explorer options in Silentum Wallet are two, blockstream and mempool.

https://talkimg.com/images/2024/05/20/142PC.jpeg

I will attend a discussion about Silent Payment here for my knowledge.

I find this silent payment mechanism to be incredibly intriguing, Through the utilization of the public key issued by user A and its combination with user B's private key, we are able to generate a distinct address exclusively accessible to user A. Consequently, it becomes exceedingly challenging for external observers to establish a connection between said address and user A, thereby ensuring the preservation of privacy.
Furthermore, I have also observed that this silent payment mechanism offers incentives for recipients to maintain the operation of their complete Bitcoin nodes. As a result, the network attains a heightened level of decentralization and security. Additionally, by enhancing the fungibility of Bitcoin transactions, this mechanism significantly contributes to safeguarding our privacy and upholding the integrity of transactions.

Couldn't agree more that something is either fungible or isn't. You can't have something partially fungible, just a little bit of fun. Could you imagine if the bank rejects a deposit into your own account, yikes, the banks & fiat is looking like a not so fantastic future. I wish it could get better and just incorporate bitcoin & then somehow all of us just don't have to pay taxes. That would be incredible lol

It is important to mention this: This de-anonymization becomes "exceedingly challenging" depending on the receiver's behavior. If the receiver consolidates all his donations (as an example of a good use case for silent payment), then the overall privacy gains are reverted, because all the senders can now see all the donations of other people. Therefore, silent payments offer privacy as long as you're careful with coin control. For example, don't consolidate more donations than needed in a transaction, preferably only one each time.

Correct, I think we must have made clear, since we have been a lot vocal about it, that in general, Bitcoin works better with coin control. Not only for privacy reasons, but also for better fee management.

Warning fo people who still haven't realised how important coin control is:

Your Bitcoin wallet -although digital- works exactly like your physical wallet not like your bank account.
If your Bitcoin wallet says: 0.15BTC, it means that all the UTXOs that you have in your wallet sum up to 0.15BTC, but you can spend each UTXO separately. Just like you could have $1000 in your physical wallet, but you could spend each dollar individually. In the bank account, there is only a digital balance and each time you spend money, it reduces the available amount respectively.
Imagine paying for a TV that costs $1000, using 200 x $5 bills. Wouldn't you try to find a more convenient way to pay? Like using 10 x $100 or 5 x $200?
Each actual dollar bill that you have in your physical wallet, corresponds to a UTXO that you hold in your Bitcoin wallet.

You must use UTXOs wisely because if you don't, you will end up either ruining your privacy, or -even worse- overpaying transaction fees.

That's like a "pay2spy" solution for chain analysis companies. They'll have to donate before they can link transactions.

Kinda :P One large difference is that in Bitcoin, you can choose your own denomination. I've seen altcoins (BlackBytes) that have fixed denominations (like banknotes). In Bitcoin, unlike banknotes, your change is always one input.

I think this is a lovely idea but, one of the many things the blockchain technology is known for is the level of transparency that is about the network.
I think to some extent, it’s the role in which mixers operated, given that you lose traces to the source of Bitcoin deposits except for one who is really keen to observe the inputs and outputs.

This silent system, does it also applies to the balance that might be available on an address?
I see this as one key aspect to privacy that we aren’t getting on the network just yet. Having just anyone to see how much is available on an address isn’t a best way to security. Tie that address to a person like we have on the forum, even though to some we are anonymous, it means trouble. The mixers case came close to some of these uneasiness.

It would be a nice incorporation into the system but, one that would be exploited for sure.

That's another problem, and this is why silent payments and stealth addresses are not enough. You need to break traceability, and that's only possible if you hide your inputs amongst a crowd, hence mixing. If for each input, there are several other "inputs-suspects", as in Monero, there is minimum information a chain analysis company can extract.

One could argue that Bitcoin is a better implementation of cash. I totally agree with you, and it's good that you mention it for newer members to see it.

Bitcoin doesn't change, the blockchain with all addresses is still public. But nobody else will know which address received a transaction that belongs to a "silent" address. There is no silent address on-chain ;)