Published on: 2013-05-28T05:16:41+00:00
Tamas Blummer has shared a JSON file on GitHub that contains test vectors for Bitcoin Improvement Proposal (BIP) 32. The JSON file can be accessed at https://github.com/bitsofproof/supernode/blob/master/api/src/test/resources/BIP32.json. Along with the test vectors, Blummer has also provided Bits of Proof code that matches with them. The code can be found at https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java. Additionally, Blummer has attached a signature.asc file to the message.In an email thread discussing BIP 32, Michael Gronager points out the confusion caused by the current formulation of the BIP text. He suggests using better terminology such as type-1 and type-2 derivation instead of "public derivation" and "public derivation function". Gronager explains that the motivation for private derivation is to avoid revealing known values like K, c, and k_i, which could lead to the discovery of other values. He mentions that there are already other implementations available, such as a Python implementation by Felix Weis and Java code in Bits of Proof. Gronager emphasizes that implementing a deterministic wallet involves more than just key derivation; it also includes detecting new keys/chains being used, lookahead, and how to use accounts.In a reply to Gronager's comment, a member of the bitcoin-development mailing list explains that sharing the master public extended key with an auditor would allow them to see all transactions from and to the wallet, in all accounts, without revealing a single secret key. The original poster had attempted to implement this concept based on documentation and code from sipa's repository on GitHub, but was waiting for further implementation before proceeding. The email also includes an advertisement for New Relic's application performance monitoring service.It is clarified in another email that the statement regarding audits through the Master Public key, M, is incorrect. Only incoming and outgoing transactions of publicly derived wallets will be part of the audit. Privately derived wallets cannot be obtained. However, addition points from privately derived wallets can be shared without loss of security: (m/i')*G. It is emphasized that there is no concept of a single public master key. To provide full access to the list of incoming and outgoing payments, an auditor can be given the master public extended key. This will enable them to view all transactions from and to the wallet in all accounts, but not a single secret key.In an email to himself, Michael discusses the private derivation in the BIP and concludes that it is intentional. He explains that while (m/i/j/k)*G = (M/i/j/k), (m/i'/j/k)*G does not equal (M/i/j/k) and results in an error. However, ((m/i')*G)/j/k = (m/i'/j/k)*G. Michael believes that the private derivation is motivated by the desire to avoid revealing known values like K, c, and k_i since they could lead to the discovery of other values as well. He expresses concern that many people may fall into this trap.In an email to Pieter, Michael expresses his concerns about BIP0032 and the equations used for private and public derivation. He notes that there can only be one HMAC function used for both types of derivation. After analyzing the formulas for private derivation, he finds that they result in K_i = k_i*G = I_L*G + k_par(mod n)*G. However, the formula for public derivation results in K_i = (I_L+k_par)*G = I_L*G + K_par, which is not the same as the previous formula. To address this, Michael suggests changing the private child key derivation to CDK((k_par, c_par), i) -> (k_i, c_i), where I = HMACSHA512(c_par, X(k_par*G)||i). He proposes splitting I into I_L and I_R (256 bits each), resulting in k_i = k_par + I_L and c_i = I_R. For pure public derivation, where the private key is not known, Michael suggests using CDK'((K_par, c_par), i) -> (K_i, c_i), where I = HMACSHA512(c_par, X(K_par)||i). He explains that by splitting I into I_L and I_R, K_i = K_par + I_L*G (= k_par*G + I_L*G = (k_par+I_L)*G = k_i*G), and c_i = I_R. These changes ensure the right properties and equal c_i values for both types of derivation.Overall, these discussions highlight the complexities and considerations involved in implementing BIP 32 and emphasize the importance of using proper terminology and equations to avoid confusion and potential security risks.
Updated on: 2023-08-01T05:03:13.982594+00:00