IntroductionIn 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 ideaThe 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 worksSay 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/c43b79517e7cb701ebf77eec6dbb46b82]
https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki3]
https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki4]
https://en.m.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman5]
https://bitcoinops.org/en/newsletters/2022/04/06/6]
https://bitcoinmagazine.com/technical/bitcoin-silent-payments-secret-keys7]
https://bitcoinmagazine.com/technical/improving-bitcoin-privacy-with-silent-payments8]
https://gist.github.com/w0xlt/72390ded95dd797594f80baba5d2e6ee
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:
