BIP352: Silent Payments

Summary:

Since June, there have been several rounds of review and revision for the BIP (Bitcoin Improvement Proposal) for Silent Payments. The BIP has been updated with a python reference implementation and wallet test vectors. Some of the major changes include using 33-byte compressed keys instead of 32-byte x-only keys, negating the private key if necessary when spending taproot outputs, and adding a versioning scheme for silent payment addresses.The implementation for Bitcoin Core reflecting these changes can be found here: [GitHub link](https://github.com/bitcoin/bitcoin/pull/27827). The full specification, including the overview, test vectors, and appendix on light client support, can be found here: [GitHub link](https://github.com/bitcoin/bips/pull/1458).The document defines Silent Payments v0 and communicates the version through the address, similar to Segwit addresses. Future upgrades to silent payments will require a new version, but as much as possible, future upgrades should support receiving from older wallets. Compatibility with older versions is important, and any changes that break compatibility should be a new BIP. A versioning scheme is outlined for future Silent Payments versions.A transaction is considered a Silent Payments v0 transaction and must be scanned if it meets certain criteria, such as containing at least one BIP341 taproot output and having at least one input from the Inputs For Shared Secret Derivation list. Transactions that spend a new, undefined output type are skipped to ensure forward compatibility with future versions.A silent payment address is constructed using various steps, including encoding the receiver's public keys and using Bech32m encoding. The address requires more characters than the limit imposed by BIP173, so it is recommended to use a higher character limit. An outpoints hash is calculated by collecting each outpoint used as an input to the transaction and sorting them. Inputs For Shared Secret Derivation is a list of UTXOs that can be used to fund the transaction, with some exclusions for conditional branches or multiple public keys.Different types of inputs, such as P2TR, P2WPKH, P2SH-P2WPKH, and P2PKH, have specific rules for the sender and receiver. The sender selects inputs based on certain restrictions, including having at least one input from the Inputs For Shared Secret Derivation list and excluding inputs with witness version > 1. The sender then creates outputs by collecting private keys, performing tweaks, and generating the outpoints_hash. Change outputs can also be created if the sending wallet implements receiving silent payments.The receiver needs two keys, the spend key and the scan key, which can be generated independently but are recommended to be derived using BIP32 derivation. After performing checks on the transaction, the receiving wallet generates the outpoints_hash and uses it to check for outputs. If an output matches, it is added to the wallet. If the wallet has precomputed labels, it checks if a match exists and adds it to the wallet.These are the main points of the Silent Payments specification, covering the changes, versioning scheme, scanning transactions, address encoding, outpoints hash calculation, inputs for shared secret derivation, sender and receiver processes, and key derivation. The full specification provides more detailed information and can be accessed using the provided links.Silent payments introduce a new address format and protocol for sending payments, but they are not compatible with older wallet software or wallets that have not implemented the silent payments protocol. Regular backups are recommended for silent payment outputs because each address is derived independently. When recovering from a backup, the wallet needs to scan since the last backup to detect new payments. If a seed/seed phrase backup is used, the user can recover the wallet's unspent outputs from the UTXO set and recover the full wallet history by scanning the blockchain. It is important to include labels or change addresses information in the backup, and if the user is unsure whether labels or the change label were used, it is recommended to always check for the change label when recovering from backup. Precomputing a large number of labels is also suggested to ensure the wallet can recover all funds from only a seed/seed phrase backup.The rationale behind silent payments includes addressing privacy and cost concerns without relying on out-of-band notifications, which could be unreliable or censored. Allowing for more than one output provides privacy improvement techniques such as CoinJoin and hiding the change amount. Inputs without public keys can still be spent in the transaction but are ignored in the Silent Payments protocol. Using all inputs helps light clients by simplifying the implementation and allowing them to use BIP158 block filters to determine if any outputs belong to them.Silent payments recommend using taproot outputs and SIGHASH_DEFAULT or SIGHASH_ALL flags for compatibility and security reasons. Skipping transactions that spend unknown output scripts allows for a clean upgrade path for Silent Payments without scanning the same transaction multiple times.

Updated on: 2023-08-07T17:42:18.430833+00:00