0

I am aware that the generator point (G) in Ecdsa is constant... But if I we're to calculate an equation using this number, I don't know if I should use the compressed or the uncompressed format of the generator point (G). And how should I apply the numbers to avoid these gaps on the numbers...

Compressed(G) :02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798

Uncompressed(G) :04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8

Dave Kent
  • 29
  • 6
  • 1
    What kind of equation? If you mean elliptic curve equations, the serialization shouldn't matter (they're to be treated as pairs of coordinates, not bytes). If you mean equations in the sense of cryptographic constructions that take hashes of points, it may matter. Can you clarify? – Pieter Wuille Jun 16 '20 at 01:21
  • Yes of course... The equation is not coordinate specific... It falls on hexadecimal arrangement like this (6g4uo358pi2996jo) or something like this :(0279BE667EF9DCBBAC55A06295CE870B07029BFCDB) instead of placing it separately like the original numbers above. I'm just trying to add it like how I would add/divide/subtract a normal hexadecimal number – Dave Kent Jun 16 '20 at 02:21
  • G is not at all constant in ECDSA; ECDSA supports about a hundred different curves each with a different G. G is constant for an EC curve (or more exactly parameter set based on a curve) and the value you posted is the G for secp256k1 which is the curve/parameters used in Bitcoin. But a point (G or other) is not a number and should not be treated as a number. – dave_thompson_085 Jun 17 '20 at 04:25
  • thanks a lot... this has put a lot of clarification in my thoughts. but if i may ask, is the G for secp256k1 constant? and if it is, in which format is it in (hexadecimal, decimal, e.t.c). thanks in advance – Dave Kent Jun 18 '20 at 20:44

0 Answers0