Author: Alan Reiner 2013-06-26 15:29:50
Published on: 2013-06-26T15:29:50+00:00
The discussion is centered around the complications of designing a wallet system that can handle multiple chains and addresses. BIP 32 defines M/i/j/k, where j=0 is the "external" chain used for distributing addresses, and j=1 is the "internal" chain for sending change. The extended wallet would have chains with j>=2 carved out for individual relationships with wallet code to individually associate each j-value with a particular identity. The wallet code will pool all the addresses in all j-chains when calculating the balance of the wallet and/or creating transactions. The wallet would have extra functions to "Receive Bitcoins" button to allow creation of new contacts/identities. When choosing to generically "Receive Bitcoins", it will pick the next address from the j=0 chain. Add code to figure out lookaheads for each alternate chain. There will be an interface to display and choose the different chains in your wallet and export the pubkey&chaincode in some soon-to-be-standardized format. There is also code and an interface to receive and track alternate j-chains from other clients/users and maintain those. It was proposed that payment protocol work be furthered along to define an extension that lets you send payment requests containing public keys+chain codes so further payments can be made push-style with no recipient interaction (e.g. for repeated billing). While the multi-chain idea is good, it complicates the developer complexity and interface complexity to achieve something much simpler. On another note, there were concerns related to automatic payments without requesting from the other party.
Updated on: 2023-06-06T18:56:25.157947+00:00