Published on: 2013-08-09T21:51:00+00:00
The discussion on the Bitcoin-development mailing list revolves around the payment protocol and alternate address serialization. The payment protocol is designed to be easily extensible and can include additional fields like "publickey" and "multiplier" in the PaymentDetails or Output messages. This allows the server to send more information to the wallet software. The alternate address serialization proposed in the discussion aims to provide better security by preserving privacy and allowing the sender to send reliable payment addresses without the risk of MITM attacks or compromise.Developers are implementing multi-chain ideas, which require significant effort to support compared to the simple alternate encoding. This may pose challenges for developers of lightweight clients and add extra burden on users to manage their wallets. BIP 32 specifies how to use the first three tree levels (M/i/j/k), but it does not cover the generation of multiple receive chains or separate ledgers and balances. The developers discuss various proposals for generating and receiving payments into BIP32-style addresses, including passing Kpar and cpar or using static public keys for persistent identity and security.In the discussion, Alan Reiner suggests an alternate address serialization that can be safely ignored by others and supports independent address chains for individual relationships. Mike Hearn mentions that the payment protocol is locked down for v1 and suggests an extension to send payment requests containing public keys+chain codes for push-style payments without recipient interaction. Jeremy Spilman proposes sharing the public key and chain code from [m/i'/0] for receiving payments at [m/i'/0/k]. The discussion also explores the idea of using static public keys for persistent identity and security. The developers agree that if designing for long-term relationships, a mechanism for generating address chains could be built in to eliminate the need for further communication after the initial exchange. They also discuss the possibility of supporting separate ledgers and balances for sub-wallets. The email exchange highlights the importance of balancing developer complexity and interface complexity while achieving the desired functionality. The goal is to improve security and convenience without complicating the wallet.
Updated on: 2023-08-01T05:36:10.860931+00:00