hft
  • Member for 6 years, 4 months
  • Last seen this week
comment

yep yep, gotcha!

awarded
comment

I updated the answer. I'm guessing this is probably answered elsewhere on this forum as well...

revised

added 155 characters in body

Loading…
comment

OK, I think maybe I see what you are getting at... But I would contend that, in some sense, it is "mostly" the x-coordinate that gets hashed, and only "a little" the y-coordinate (just effectively the sign of y--the y value is implicit). In other words, in practice, the public key (a curve point) must be converted to a byte string in order to be processed by the hash function. This conversion to bytes is performed by converting the x-coordinate to a byte string and then appending either 0x02 or 0x03 to the front of the byte string to account for the sign of the y-coordinate.

comment

you are welcome. One other nitpick: it is just SHA256, not SHA256d that is applied prior to the RIPEMD-160 hash when forming the unchecksummed address hash.

revised

added 69 characters in body

Loading…
comment

The part in Nit (1) about multiple address is a valid nit, but maybe too much info for OP to handle? Anyways, I updated the answer to reflect nit 1 as well.

comment

Re (2): Yes, I agree, that was inaccurate, I updated the answer to state greater than 0 and less than n. Re (1): Since I didn't specify the hash function, the part in nit (1) about the hash doesn't technically apply. (A hash function that is the action of ripemd160 on the sha256 of '\x02'+x-coordinate is still a hash function. Similarly appending on the checksum is still a hash function.) Since the function can be applied to arbitrary input and produces a fixed size output, it's still a hash function.

revised

added 27 characters in body

Loading…
revised

deleted 2 characters in body

Loading…
comment

See section 2.4.1 here: secg.org/sec2-v2.pdf

comment

I think the range of the private key is actually limited to the order "n" of the generator, which is close to 2**256, but not equal to it. The order is 115792089237316195423570985008687907852837564279074904382605‌​163141518161494337

comment

Just to add a little color: the number of private keys is way way way bigger than a quadrillion. It is more than 115 quadrillion quadrillion quadrillion quadrillion quadrillion. The limit on the number of private keys is the order "n" of the Generator, which is "fairly close" to 2 raised to the 256 power. The actual value of "n" is: 115792089237316195423570985008687907852837564279074904382605‌​163141518161494337

answered
Loading…
revised

added 47 characters in body

Loading…
comment

Yeah, that's true. I guess I didn't parse the question fully. (But apparently well enough to answer the question OP must have had in mind.) I didn't mean to imply that the script interpreter has to tell the difference--just that OP can tell the scripts apart using the suggested method. I edited my answer.

revised

deleted 19 characters in body

Loading…
revised

added 5 characters in body

Loading…
comment

You could tell because there would be no need for the "OP_DUP OP_HASH160 Public-Key-Hash OP_EQUAL" sequence.