Topic: BIP32 Child Derivation Function - Can't Find My Mistake (Read 205 times)

Yeah, so I have no idea what the standard is for converting negatives to hex is here. but it's whatever -7bd3305d363c26f82c1e41c667e4b3561c06c60a2104d2b548e6dd059056aa51 would be represented as, in any case.

Ah, yes, it was my decompression of Y. I had my suspicions. You helped me narrow it down quite a bit, actually. Thank you for your assistance.

Can you print them in hex? The negative makes things slightly harder to check things.

The X component of m's Pub is correct and iL * G is also correct.

I already did. They're in the final quote under the names il * G  and m's ECpub respectively.

Also, Point::add and Point::mul are used in my recoverPubKey function for verifying signed messages, which I'm already sure works correctly for multiple coin types. However, I can't completely rule out the possibility of an issue, which is why I'd like verification on the numbers and the results, as you say.

Before you do the adding, can you print out what you get for
and

Make sure that those are what you expect them to be.

The only thing that can be wrong here is that either you are adding the wrong things or Point::add is broken.

I'm working on a Public-key-only BIP32 script to track purchases on my website rather than having users sign messages to verify themselves as the purchaser, and I spent yesterday getting the code together for it. The primary extended public key (m) code is now fully functional, but deriving children is running into issues. I've been testing with TestVector 02 (xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8id oc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB), and have successfully generated this data with the key:

When I begin derivation of m/0, however, I get this far and then things end up wrong:
Of course, m/0 should be 19EuDJdgfRkwCmRzbzVBHZWQG9QNWhftbZ, not 1XMqymHzMur3pkEXr29pr8ghZbJkNWPw4. In comparing with https://en.bitcoin.it/wiki/BIP_0032_TestVectors, I can verify that the Chain Code matches, so up to the SHA512 hash must be working correctly, however, the X/Y coordinates are completely wrong, resulting in the wrong key. The actual values for the left-side-of-I and the X/Y coordinates I'm ending up with are:
Since the chances of my iL being wrong are virtually impossible because the Chain Code is right, my best guess is my point math must be off. The code I'm using is:
where $il is a big-integer version of iL above, $secp256k1_G is the G Point, and $this->ECpub is the parent key's Point (decompression of Key's Bytes of course).

Here's the function in its entirety:

Points, CurveFPs, and all that good elliptical shit are handled via a stripped down version of Matyas Danter's phpecc, so I'm pretty sure the actual mathematics I'm calling are good there, but the outcome for $k is always ending up as d83bc1ba1544900181dc0a68f70c7f35de329935252d6a8a69609f18613e57e2 rather than fc9e5af0ac8d9b3cecfe2a888e2117ba3d089d8585886c9c826b6b22a98d12ea, and I can't figure out for the life of me why.

For reference, the point I'm getting when multiplying iL and g is x=b661389998a7d5f191064dd13de77d6ecdc180660cd035c39e4242e4b2421b04, y=e4b7d21882264392ba68ab5a91fa6a7eb7794273e6887cbbcc367f0fc1a711be. I have no idea if this is correct or not, but I know that once I add the parent's public curve, it ends up being completely wrong. So, please, if anyone could have a working implementation spit out the points for iL * g, the parent key, and k, I'd like to know where I'm going wrong.

My own results, in decimal, are as follows:

The negative y on the parent's ECpub sorta makes me anxious, but the key output is right for "m", so it must be correct, yes?