Published on: 2012-12-05T03:50:17+00:00
In an email exchange, Watson Ladd discussed the implications of being able to spend a coin sent to an address generated by a scheme and explained that it implies being able to spend any coin generated by the same scheme. However, having only the plain ecdsa secret is not enough to spend anything but that specific address.Ladd then went on to discuss the construction of deterministic wallets, suggesting that using a stream cipher to generate random bytes for private keys in a wallet is the easiest method. However, he noted that this method does not add any additional benefits other than distinguishing transactions by sending to unique addresses, which could be done through other means.Ladd also mentioned that this type-1 deterministic wallet construction has no ability to separate address generation from spending, which is important for merchant applications and limited privacy properties of the Bitcoin system. He previously referred to this construction as one of the different derivation schemes in a forum post and highlighted BIP32's hope to use a single deterministic wallet construction.In an email conversation between Gregory Maxwell and Mike Koss, Koss proposed a new alternative to the BIP 32 proposal. His proposal was based on a hierarchical string representation, rather than hierarchy of integers as proposed in BIP 32. Koss named keys using this representation style.However, Maxwell pointed out that blindly iterating through strings is not possible, which means that Koss' proposal loses the backup recoverability property of a deterministic wallet. Maxwell also noted that both BIP 32 and Koss' proposal have a missing feature: being able to spend a coin sent to an address generated by this scheme implies being able to spend any coin generated by this scheme.Maxwell suggested that the easiest deterministic wallet construction is simply to use a stream cipher to generate random bytes used as the private keys in a wallet. Additionally, Maxwell mentioned that Koss' extended hierarchy of multipliers made him uncomfortable. On the other hand, the multipliers at each level in BIP 32 are unstructured, but the ones in the next level are products of the ones before. This creates a multiplication tree with random-looking branches.In December 2012, Mike Koss proposed an alternative to the BIP32 proposal for a deterministic wallet system based on a hierarchical string representation. He named keys using a specific format: [hd1.75491111].store.x. Pieter raised concerns that blindly iterating through strings is not realistically possible and could result in losing the backup recoverability property of a deterministic wallet. This means that if a backup is made prior to establishing a new string name, it must also have a reliable backup of the string as well. Furthermore, if the backup of strings is incomplete with the hierarchical string representation, some or all assigned coin may be lost forever.On the other hand, with the BIP32 scheme, backing up a map equating the hdwallet indexes to strings would allow for no loss of coins (only metadata) in the event of a catastrophic loss where only the original ultimate root is left.The author has created an alternative to the BIP 32 proposal, which uses a hierarchical string representation instead of an integer hierarchy. He names keys based on this system and envisions using it in services. The author has not done any work to recommend how keys would be represented directly in the client. The author is looking for feedback on any security concerns with their scheme and whether not introducing the enlarged key space that BIP 32 does represents a weakness of their scheme versus BIP 32. The author is happy to release their source code (Python) but wants to get feedback first.In response to a question about serializing points using a compressed format before going into the hash function, Pieter Wuille suggests standardizing on just compressed keys since they take less space in the blockchain and there is no additional value in uncompressed keys. The software may continue to support uncompressed keys for compatibility, but for a new standard, compressed keys make sense. The encoding itself is not hard, just 0x02 or 0x03 followed by the 32-byte encoding of X. Decoding is harder but is never needed in the derivation. Decoding compressed public keys is somewhat harder as Y must be reconstructed, but this is only necessary when someone wants to import an extended public key for watch-only wallets.
Updated on: 2023-08-01T04:23:03.213535+00:00