Published on: 2013-06-26T15:29:50+00:00
The discussion revolves 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 email thread discusses the issue of proving a payment to a third party who has not seen the communication between payer and payee. The solution proposed involves using PubKeyParent and HMAC (Multiplier, PubKeyParent) to calculate the destination address, which can then be provided to the third party as proof of payment. The use of Timo's suggestion is also discussed, but it would require deviation from BIP 32 standardization. The importance of supporting both solutions is emphasized, rather than introducing extra wallets/chains.The context discusses the challenge of proving a payment to a third party who has not seen the communication between the payer and payee. The HASH160 is the only information that the third party has. The problem arises when the payee denies receiving the funds, as it's easy to prove what public key it was sent to (the preimage), but you can't prove the parent of that public key. However, a solution proposed by Timo suggests calculating the destination using PubKeyParent * HMAC(Multiplier, PubKeyParent). If this method is used, providing the 3rd party with a PubKeyParent and Multiplier that produces the destination address would prove the payment is spendable by PubKeyParent, leaving no room for denial.The discussion takes place between two individuals, Jeremy and an unidentified person, about the implementation of HD wallets in Bitcoinj. The unidentified person suggests defining an extension that allows for the push-style sending of payment requests containing public keys and chain codes. They also mention experimentation with how apps will arrange their chains internally. Jeremy mentions that BIP 32 already specifies the use of the first three tree levels: M/i/j/k, and that creating new wallets would not be free unless the levels are redefined.In this conversation, Jeremy is discussing with Alan the limitations of BIP32 in using multiple chains. He mentions that BIP32 does not prescribe a way to use multiple chains like the one he described. He also questions the need for a 128kB hardware wallet as it is only a signing device and doesn't listen on the P2P network. Jeremy emphasizes the benefits of gaining critical mass support for a technique that can be used in all cases, increasing security and privacy for everyone involved. He believes there are huge benefits in leaving the age of single address generation behind us.The discussion is about the use of PubKey and ChainCode for forming a persistent relationship between two parties using BIP32. The author suggests that exchanging PubKey and ChainCode beforehand can help in transaction securely forever without ever exchanging any more information, and without any address reuse. They propose that wallets should always dedicate a new child node {PubKey, ChainCode} to each party they transact with.An alternative address format is proposed in the context, which is made possible by BIP 32. The purpose of this new format is to specify a "Wallet ID" and "One-time payment" code instead of the standard one-use Base58-Hash160 addresses. This format allows parties with a persistent relationship to prove that payment addresses they provide each other are linked to a particular wallet. It reduces exposure to Man-in-the-Middle (MitM) attacks without the need for SSL or a web of trust, while maintaining the privacy of both parties.One suggestion discussed in the conversation is the use of ECDSA signatures for type2 public keys, which are multiples of a parent public key. The proposal suggests sending an ECDSA signature of the multiplier, which can be used to compute the parent public key. However, there are concerns about the unknown discrete log artifact and potential vulnerabilities. One solution proposed is to require a proof of knowledge of the discrete log, such as including an ECDSA signature or Schnorr proof of knowledge in the address.Another issue raised is the possibility of generating arbitrary pairs of {PublicKeyParent, Multiplier} that lead to the same address. This could be undesirable depending on what the transaction should prove. To address this, the suggestion is to replace PubKeyParent * Multiplier with PubKeyParent * HMAC(Multiplier, PubKeyParent). However, it is noted that the most obvious attack vector is the discrete log problem, where an attacker tries to find the multiplier that solves M * PubC = PubB.The conversation also explores the idea of an alternate way of encoding an address using {PubKey, Multiplier}.
Updated on: 2023-08-01T05:10:15.707119+00:00