Third version of Silent Payment implementation [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2022-10-03T23:41:10+00:00


Summary:

In a recent clarification provided by Ruben Somsen, the function of the identifier in bitcoin addresses was discussed. The purpose of this identifier is to distinguish why someone has made a payment to you. However, it is important to note that third-party observers are unable to link these payments on-chain and cannot determine which identifier was used. In situations where you do not want your identity to be revealed, the identifier alone is insufficient, and a separate Silent Payment address is required.Ruben also introduced a scheme that allows for multiple silent addresses per wallet with minimal overhead. This scheme enables the resulting address to be marked in a recognizable way, allowing the recipient to differentiate between different payment purposes. To implement this scheme, a public identifier "f" is added to a key when tweaking. It is essential to communicate this identifier to the sender, possibly as part of the address format. The new address format includes a field called "identifier," which guides both the receiver and sender in setting the address correctly. If the receiver is unaware of which identifiers have been used, the wallet can scan all identifiers from 0 to 99. Currently, each wallet is limited to using only 100 different identifiers, but this limit can be increased in the future if needed. Furthermore, a new RPC (Remote Procedure Call) has been implemented to retrieve silent addresses. Users are now able to assign different labels to their addresses, allowing them to identify which silent address a specific UTXO (Unspent Transaction Output) came from. This feature enhances usability and organization within the wallet. It should be noted that the newly introduced silent payment (SP) addresses are not script-related, which means they can potentially include additional information, such as an expiration timestamp or block height in the future. To assist users in understanding and implementing this scheme, a step-by-step tutorial has been provided on Github. This comprehensive tutorial serves as a reference guide for users interested in utilizing the new scheme proposed by Ruben Somsen.


Updated on: 2023-08-02T07:43:10.225110+00:00