Silent payments

[LoyceV]

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

As far as I understand, this is incorrect.

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.

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.

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

[witcher_sense]

But silent payment will not be transparent as it is not even existing on blockchain at all and the public will 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.

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.

[Charles-Tim]

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.

---snipped---

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.

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

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.

[oryhp]

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.

[Accardo]

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?

[BlackHatCoiner]

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.

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.

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

[LoyceV]

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?

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.

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.

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

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

[AverageGlabella]

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.

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.

[BlackHatCoiner]

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.

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. 

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 only need to derive millions of addresses from one master public key, and save those with a balance.

[oryhp]

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. 

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.

[n0nce]

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

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.

There were 5,868,096 total transactions, for an average of 16,076 transactions per day for the year

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?

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.

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.

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.

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

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.

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

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.

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?

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

[witcher_sense]

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?

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.

[BlackHatCoiner]

Quoting part of the OP:

Therefore, that allows user A to receive payments on completely delinked addresses using only one public address.

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?

[witcher_sense]

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.

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.

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?

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.

[rlirs]

Quoting part of the OP:

Therefore, that allows user A to receive payments on completely delinked addresses using only one public address.

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?

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.

[BlackHatCoiner]

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.

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.

Previously, Alice had one address with many outputs created by different senders

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

Let me show you.

Code:

 With master public key:


┌───────────┐ m/84'/0'/0'/0/0     ┌────────────┐  bc1q8g4...fjyjy       ┌────────────┐
│ Home node │◄───────────────────►│   Server   │◄──────────────────────►│ Visitor #1 │
└───────────┘                     └────────────┘                        └────────────┘



┌───────────┐ m/84'/0'/0'/0/1     ┌────────────┐  bc1qeud...ccr6f       ┌────────────┐
│ Home node │◄───────────────────►│   Server   │◄──────────────────────►│ Visitor #2 │
└───────────┘                     └────────────┘                        └────────────┘



┌───────────┐ m/84'/0'/0'/0/2     ┌────────────┐  bc1qwzx...2dxz7       ┌────────────┐
│ Home node │◄───────────────────►│   Server   │◄──────────────────────►│ Visitor #3 │
└───────────┘                     └────────────┘                        └────────────┘


 Et cetera.

Code:

                                                  ┌────────────┐   03aae...ccdf7       ┌───────────────────┐
                                          ┌──────►│ Visitor #3 ├──────────────────────►│ Construct Address │
    With silent payments:                 │       └────────────┘                       └───────────────────┘
                                          │
                                          │
     ┌────────┐    02efa...e4da1          │       ┌────────────┐   03da2...64a2d       ┌───────────────────┐
     │ Server ├───────────────────────────┼──────►│ Visitor #2 ├──────────────────────►│ Construct Address │
     └───┬────┘                           │       └────────────┘                       └───────────────────┘
         │                                │
         │                                │
         │                                │       ┌────────────┐   02d80...239e1       ┌───────────────────┐
         │                                └──────►│ Visitor #3 ├──────────────────────►│ Construct Address │
         │                                        └────────────┘                       └───────────────────┘
         │
┌────────┴─────────┐
│ Scans the chain  │
└──────────────────┘

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

Advantage of silent payment would be if Alice receives many payments and cannot reply to senders.

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

It would be more interesting to hide sender, not receiver. Maybe silent payments together with help of miners can break connection with senders.

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

[rlirs]

It would be more interesting to hide sender, not receiver. Maybe silent payments together with help of miners can break connection with senders.

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.

[LoyceV]

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.

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.

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

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.

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

Code:

 With master public key:


┌───────────┐ m/84'/0'/0'/0/0     ┌────────────┐  bc1q8g4...fjyjy       ┌────────────┐
│ Home node │◄───────────────────►│   Server   │◄──────────────────────►│ Visitor #1 │
└───────────┘                     └────────────┘                        └────────────┘



┌───────────┐ m/84'/0'/0'/0/1     ┌────────────┐  bc1qeud...ccr6f       ┌────────────┐
│ Home node │◄───────────────────►│   Server   │◄──────────────────────►│ Visitor #2 │
└───────────┘                     └────────────┘                        └────────────┘



┌───────────┐ m/84'/0'/0'/0/2     ┌────────────┐  bc1qwzx...2dxz7       ┌────────────┐
│ Home node │◄───────────────────►│   Server   │◄──────────────────────►│ Visitor #3 │
└───────────┘                     └────────────┘                        └────────────┘


 Et cetera.

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.

[BlackHatCoiner]

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

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

What if you have billions of page loads?

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

[hZti]

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.