2

As describe by Maxwell here in HD wallets assuming we have a key pair with private key SK.a and public key of PK.a and a seed s and a generator point G, we can generate a new key pair of (SK.b, PK.b) as follows:

PK.b = PK.a + sG
SK.b = SK.a + s

The advantage with this method is that a service provider can generate new public keys without knowing the clients private key. My question is that, why don't we multiply the seed and private key rather than adding them?

PK.b = PK.a * s
SK.b = SK.a * s

Is there any problem with the later method that I suggested?

2

A previous draft of BIP0032 did this, actually. (Sorry about linking to the bitcoin wiki - that change was made before we switched over to git for BIP tracking.)

According to the changelog, it was done for speed reasons.

  • [30 Apr 2013] Switched from multiplication by IL to addition of IL (faster, easier implementation)

It's much faster when deriving a child private key from a parent private key. The new method requires only a normal addition (mod n) rather than an ECDSA point multiplication.

It's not faster when deriving a child public key from a parent public key. That still requires an ECDSA multiplication followed by an ECDSA addition. (In fact, it's about 2% slower.)

Using addition does not add any security issues. It's possible to get a parent private key from a child private key and an extended public key, but that would also be true if multiplication was used.

  • Thanks for the answer! As I also expected, it should be due to the performance and efficiency. However, doesn't multiplication makes it stronger in terms of security? In addition, finding the master public key based on children's public key would be easy for an attacker I suppose? He just needs to subtract a children's public key by different number (brute forcing seed size) – abeikverdi Mar 8 '15 at 8:52
  • 2
    No, it does not add anything. There are no security properties that a multiplication gives that addition doesn't. The reasons for changing was that it 1) didn't improve anything 2) was faster 3) was easier to implement and 4) would not make people assume it has any properties it doesn't (people often assume that no inverse for EC multiplication exists, which is true, but only to solve for k in k*P = Q; solving for P is possible). – Pieter Wuille Mar 8 '15 at 14:23
  • @PieterWuille can you elaborate a bit more on your last sentence? What do you mean by solving P is possible? – abeikverdi Mar 9 '15 at 8:10
  • @abeikverdi This is getting out of scope of the original question, so I made a new question. – Nick ODell Mar 9 '15 at 9:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.