Stealth Addresses [combined summary]



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

Published on: 2014-03-06T12:23:40+00:00


Summary:

In a series of email exchanges, developers Peter Todd and Jeremy Spilman discussed various aspects of implementing stealth addresses in Bitcoin. They discussed using a master shared secret to derive per-pubkey secrets and the possibility of adding a counter to the hash function to improve stealthiness. They also explored the use of multi-sig and P2SH outputs for better anonymity and compatibility with other wallets.In another email exchange, Spilman asked why two EC points were not used in the stealth address. Todd explained that he had implemented both pubKeys in a 2-of-2 multisig instead, to prevent false positives on the online detection key while funds are still controlled by the payer. They also discussed the process of nonce recovery with ECDH and the need for defining a reasonable stealth address spec.The conversation then shifted to integrating stealth addresses into OpenPGP keys or x.509 certs, with the aim of making them usable for P2P payments. Todd suggested replacing static address text with new 'href=bitcoin:xSTL...' URIs to encourage their usage. He also emphasized the importance of identifying the recipient and proposed adding stealth addresses to the Output message rather than the PaymentDetails field.In a separate email exchange, Spilman and Todd discussed the implementation of stealth addresses for Payment Protocol. They debated the feasibility of certain approaches, such as adding a prefix to the OP_RETURN TxOut and symmetric encryption of P. Privacy risks and potential reduced anonymity sets were considered in these discussions.Other topics covered included the under-addressed use case of non-transactional personal payments, the concept of sending "please pay me" messages, and the differences between Reiner's proposal and stealth addresses. The advantages and complexities of different payment schemes were examined, including the use of BIP32 branches and the necessity of bidirectional communication.Overall, these email exchanges shed light on the technical considerations and challenges involved in implementing stealth addresses in Bitcoin, as well as the potential use cases and benefits they offer.The scriptPubKey/transaction generation scheme known as Stealth Address is designed to allow payees to share a single, fixed address with payors. This enables efficient, private, reliable, and non-interactive fund transfers. The generated scriptPubKey must be unique globally and only spendable by the intended payee. It is essential that this method is fully deterministic so that funds can be recovered using a wallet seed and blockchain data for both the payee and the payor.Importantly, the scheme must be compatible with CoinJoin, a privacy-enhancing technique, and should not reveal any information to the payee about which transaction inputs were used to make payments to them. Additionally, it offers the flexibility to trade off anonymity set size for decreased bandwidth and CPU usage. This can be achieved by allowing the payee to specify that payments matching a short prefix, k, are acceptable.An alternative approach to increase efficiency could involve using bare OP_CHECK(MULTI)SIG outputs to hold the nonce pubkey. For multisig support, the scheme must allow for the specification of n-of-m master pubkeys using the nonce to generate derived ones.It is worth noting that addresses generated using this method will be slightly longer than standard Bitcoin addresses.


Updated on: 2023-08-01T07:12:42.080079+00:00