Bitcoin Elliptic curve point multiplication results in key ZERO

[RBan]

I was playing around with the gobittest.appspot website and I came across this:
If you multiply 12345 (3039 in hex) by this key: (04065f53171dcd7d03a71e93d74394694e6af13aef4030ce9faa3db65d627ecbcfcd75a3048ff8a 0d87bff6ec60d900e86523e3165e5bebc3bbdfc199d3a998063) you will get a key that's not on the curve.

I was able to find some info about the Zero key but it doesn't explain the multiplication results. The key i'm multiplying with is a random key so I don't know the private key for but either way the multiplication should never give a key outside the curve.

Can anyone explain how was this possible?

Here's the info on key zero

0x00: Uncompressed private key: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
Uncompressed WIF: 5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqetwr388P
Uncompressed public key: EMPTY
Uncompressed address: 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
Compressed private key: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD036414101
Compressed WIF: L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFqRzExJJ
Compressed public key: EMPTY
Compressed address: 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
~0xSkrypt

[1714174003]

1714174003

[1714174003]

1714174003

[1714174003]

1714174003

[1714174003]

1714174003

[o_e_l_e_o]

First off, multiplying two private keys together is not elliptic curve multiplication. The gobittest vanity page literally just does arithmetic multiplication of two hexadecimal numbers.

Second, it is entirely possible to generate a non-valid private key. The uncompressed private key you have generated is:

Code:

FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141

This number is called n, and is known as the order of the base point G. This is the number of times you can add the base point G to itself. Therefore, the total number of valid private keys in bitcoin is n-1. Any number of n or greater is an invalid private key.

[RBan]

First off, multiplying two private keys together is not elliptic curve multiplication. The gobittest vanity page literally just does arithmetic multiplication of two hexadecimal numbers.

Second, it is entirely possible to generate a non-valid private key. The uncompressed private key you have generated is:

Code:

FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141

This number is called n, and is known as the order of the base point G. This is the number of times you can add the base point G to itself. Therefore, the total number of valid private keys in bitcoin is n-1. Any number of n or greater is an invalid private key.

First of all thanks for your reply. The gobittest vanity page doesn't just multiply two hex numbers as far as I know, it does so based on the bitcoin curve. You can try and produce a result from any multiplication that is outside the curve and you will not be successful, thats why it was surprising to me. If you can however please share an example other than the one posted.

You also mentioned that its entirely possible to generate a non-valid private key, can you provide an example on how you would do so since the hex for this key is zero and no library will allow you to do so unless it was not coded correctly?



   

[o_e_l_e_o]

Try putting in your two private keys as two very small numbers - say "2" and "5". The resulting private key are either "7" (2+5) or "A" (2*5 - in hex of course). Sure, it then uses elliptic curve multiplication to turn those private keys in to public keys, but the process it uses of multiplying the two private keys is just straight forward arithmetic multiplication.

Try using the numbers

Code:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140

and

Code:

1

as your two private keys.

You will see that One + Two gives you the curve order (n) which is invalid and therefore gives no public key, whereas One x Two gives the FFFF...4140 number above (n-1) which is the highest valid private key and does generate a public key.

You also mentioned that its entirely possible to generate a non-valid private key, can you provide an example on how you would do so since the hex for this key is zero and no library will allow you to do so unless it was not coded correctly?

Any number higher than n-1 is a non-valid private key. It is possible to generate such a key, but I never said it would be possible to use such a key. Some pieces of software will calculate the private key modulo n though, and so turn a non-valid private key in to a valid one. You can try this on the gobittest page by using the private keys

Code:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140

and

Code:

2

The private key generated from One + Two wraps back around and gives the private key "1".

[NotATether]

If you mean this page on gobittest https://gobittest.appspot.com/PrivateKey, I entered the uncompressed WIF inside it and it gave me a private key of 9F23FFFFFFFFFFFFFFFFFFFFFFFFFFFFEF4D21CEC75756599124A862727EE62F6E5C. That private key isn't on the curve, so it's technically point at infinity (I'm not sure if this is correct though). So if you multiply it by any number you will also get point at infinity (stack exchange), which gobittest just writes as 0.

[RBan]

Try putting in your two private keys as two very small numbers - say "2" and "5". The resulting private key are either "7" (2+5) or "A" (2*5 - in hex of course). Sure, it then uses elliptic curve multiplication to turn those private keys in to public keys, but the process it uses of multiplying the two private keys is just straight forward arithmetic multiplication.

Try using the numbers

Code:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140

and

Code:

1

as your two private keys.

You will see that One + Two gives you the curve order (n) which is invalid and therefore gives no public key, whereas One x Two gives the FFFF...4140 number above (n-1) which is the highest valid private key and does generate a public key.

You also mentioned that its entirely possible to generate a non-valid private key, can you provide an example on how you would do so since the hex for this key is zero and no library will allow you to do so unless it was not coded correctly?

Any number higher than n-1 is a non-valid private key. It is possible to generate such a key, but I never said it would be possible to use such a key. Some pieces of software will calculate the private key modulo n though, and so turn a non-valid private key in to a valid one. You can try this on the gobittest page by using the private keys

Code:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140

and

Code:

2

The private key generated from One + Two wraps back around and gives the private key "1".

Thank you for the detailed explication, what you said makes sense but what I don't understand is why would multiplying the key I mentioned by 12345 (or 3039 in hex) gives zero? I tried it with a python lib and it gave a different result actually but very similar public address.
The public address produced by gobittest for the zero key is 049663999D864D6D1A79FFB0C547D19CB5A51123888AD4BDAE5CCEDB61CC3239BA4182C2088B09D 67ADEDF1BDC543B5F336D017017FF8D83E44D75A00A3D6BEE
and the public key produced by the python lib is 049663999d864d6d1a79ffb0c547d19cb5a51123888ad4bdae5ccedb61cc3239ba004182c2088b0 9d67adedf1bdc543b5f336d017017ff8d83e44d75a00a3d6bee

If you mean this page on gobittest https://gobittest.appspot.com/PrivateKey, I entered the uncompressed WIF inside it and it gave me a private key of 9F23FFFFFFFFFFFFFFFFFFFFFFFFFFFFEF4D21CEC75756599124A862727EE62F6E5C. That private key isn't on the curve, so it's technically point at infinity (I'm not sure if this is correct though). So if you multiply it by any number you will also get point at infinity (stack exchange), which gobittest just writes as 0.

I dont know that the private key is for 04065f53171dcd7d03a71e93d74394694e6af13aef4030ce9faa3db65d627ecbcfcd75a3048ff8a 0d87bff6ec60d900e86523e3165e5bebc3bbdfc199d3a998063 but its definitely not what you mentioned. So what I'm wondering is why multiplying this by dec 12345 yeild point at infinity on gobittest

[moderator's note: consecutive posts merged]

[pooya87]

what I don't understand is why would multiplying the key I mentioned by 12345 (or 3039 in hex) gives zero?

that is not mathematically possible. the point you posted in OP (04065f5...) is on secp256k1 curve and when it is multiplied by a number smaller than the curve order the resulting point is also already on curve. the correct result is what you posted in this comment (049663999....). the only reason why you get zero is possibly a bug in the tool you are using.

[RBan]

what I don't understand is why would multiplying the key I mentioned by 12345 (or 3039 in hex) gives zero?

that is not mathematically possible. the point you posted in OP (04065f5...) is on secp256k1 curve and when it is multiplied by a number smaller than the curve order the resulting point is also already on curve. the correct result is what you posted in this comment (049663999....). the only reason why you get zero is possibly a bug in the tool you are using.

I agree, a bug on gobittest seems more likely as an explanation since if I do the same operation on python I get a different key but the same public address.

[o_e_l_e_o]

I entered the uncompressed WIF inside it and it gave me a private key of 9F23FFFFFFFFFFFFFFFFFFFFFFFFFFFFEF4D21CEC75756599124A862727EE62F6E5C. That private key isn't on the curve

I'm not sure how you reached that private key. Pasting either the uncompressed or compressed WIF from the first post in to the page you linked should give you the following private key, which happens to be the curve order n, plus or minus the added 01 byte at the end if it is compressed:

Code:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141(01)

The key that you have arrived at:

Code:

9F23FFFFFFFFFFFFFFFFFFFFFFFFFFFFEF4D21CEC75756599124A862727EE62F6E5C

Not only is not valid, but is 68 characters long and significantly larger than 2²⁵⁶.

[mamuu]

what I don't understand is why would multiplying the key I mentioned by 12345 (or 3039 in hex) gives zero?

that is not mathematically possible. the point you posted in OP (04065f5...) is on secp256k1 curve and when it is multiplied by a number smaller than the curve order the resulting point is also already on curve. the correct result is what you posted in this comment (049663999....). the only reason why you get zero is possibly a bug in the tool you are using.

I agree, a bug on gobittest seems more likely as an explanation since if I do the same operation on python I get a different key but the same public address.

Maybe Bug but,  no on EllipticCurve your pubkey( in same time addresses )

May be its same ? -> https://www.blockchain.com/btc/address/1RBanRBanRBanRBanRBanRBan223RWPFp

this address recive bitcoin but can't spent. because it has no pubkey(EC point), just hash160

[o_e_l_e_o]

because it has no pubkey(EC point), just hash160

It is trivial to generate a valid bitcoin address if you don't care about being able to spend from it. As long as you start with a 1, don't use invalid characters which are not part of Base58Check encoding, and calculate the correct checksum for the last 5 or 6 characters, you can generate a valid bitcoin address. Neither you nor anyone else will know the related public nor private keys, and so any bitcoin sent to that address cannot be spent, but the address remains valid.

If you don't want to convert back to Base64 to calculate the checksum manually, you can use https://gobittest.appspot.com/ProofOfBurn to do it for you.

[NotATether]

I entered the uncompressed WIF inside it and it gave me a private key of 9F23FFFFFFFFFFFFFFFFFFFFFFFFFFFFEF4D21CEC75756599124A862727EE62F6E5C. That private key isn't on the curve

I'm not sure how you reached that private key. Pasting either the uncompressed or compressed WIF from the first post in to the page you linked should give you the following private key, which happens to be the curve order n, plus or minus the added 01 byte at the end if it is compressed:

Code:

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141(01)

The key that you have arrived at:

Code:

9F23FFFFFFFFFFFFFFFFFFFFFFFFFFFFEF4D21CEC75756599124A862727EE62F6E5C

Not only is not valid, but is 68 characters long and significantly larger than 2²⁵⁶.

I can't seem to reproduce my own answer. I was sure I entered 5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqetwr388P into the uncompressed WIF textbox, maybe I didn't drop the last 4 bytes, or mistakenly took a random WIF instead of the one I tried to type?