Post
Topic
Board Development & Technical Discussion
Re: Silent payments
by
Charles-Tim
on 27/05/2022, 15:39:47 UTC
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 private key. 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

5) Silent payments incentivize a receiver of funds to keep their own Bitcoin full node running, which automatically results in a more decentralized network.
It would be quite worth it to discuss about it, I scanned through the proposal on GitHub but I did not see anything like incentivizing the receiver of fund.

7) Silent payments greatly improve the fungibility of bitcoin transactions.
To be sincere, the process is kind of complicated and not supporting BIP32 HD keys which even BIP44, 49, 84 and 86 are using for HD key generation. I mean which defines HD wallet.

How is this a benefit, according to the proposal?

Effect on BIP32 HD keys
One side-benefit of silent payments is that BIP32 HD keys4 won't be needed for address generation, since every address will automatically be unique. This also means we won't have to deal with a gap limit.

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.
Which makes address reuse prevention not to be possible and also not favoring light clients. A complicated process that will enhance address reuse shoukd 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 about how it may not be recommended.

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.

Likely, some address types will not be supported.

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