Optional "wallet-linkable" address format - Payment Protocol



Summary:

In an email exchange between Jeremy Spilman and Alan, Alan suggests that the creation of new wallet chains is not the only operation needed to achieve the functionality he is requesting. He explains that there are orthogonal use-cases to having a single wallet serve as a single identity that can be used across multiple transactions or services. BIP 32 already specifies how to use the first three tree levels: M/i/j/k, i~wallet, j~Internal/External, k~address. However, the first level is actually type-1 derived, and thus we cannot create an arbitrary number of them without pre-computing them from the offline wallet. Alan argues that even if we assume the simplest case where the first level is actually type-2 derived and it costs nothing to create separate wallets for each contact/party, complexity arises in deciding whether extra wallet chains behave as different wallets or sub-wallets, bundling their balances into a single wallet or displaying them separately, specifying which wallet(s) to spend from, and implementing a multiple-wallet interface to handle cross-wallet spending. Alan proposes an alternative address encoding with a single wallet to support this identity mechanism, making it useful and trivial to implement even in the simplest wallet applications. However, users can still choose to create a separate wallet for certain operations to separate their identities if the software supports multiple wallets.


Updated on: 2023-06-06T18:55:29.325396+00:00