Topic: Silent payments - page 6. (Read 2764 times)

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.

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.

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

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.

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?

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':


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.

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

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?

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.

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!

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.

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.

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? 

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.

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.

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.

While the complexity could be reduced with software which has nice UI/UX. But looking at adaption of similar proposal (BIP 47 and 75), i have to agree.


If the recipient must calculate/check public key, wouldn't BIP 158 reduce the disadvantage since it's designed for light wallet?

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

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.

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.

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