Found a nice pubkey collision | Bitcointalksearch.org

o_e_l_e_o

legendary

Activity: 2268

Merit: 18711

This is not a collision, it is not the first time ever, nor is it in any way difficult to do. It is an inherent property of the secp256k1 curve that bitcoin uses. Taking the negation of any private key modulo n is the same as negating the resulting public key across the x axis. As such, the two private keys which OP has given, which are modular negations of each other, produce public keys with the same x coordinate but different y coordinates.

Here's another pair:

Code:

0000000000000000000000000000000000000000000000000000000000000002
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD036413F

which give the following two public keys:
04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee51ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a
04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5e51e970159c23cc65c3a7be6b99315110809cd9acd992f1edc9bce55af301705

franky1

legendary

Activity: 4410

Merit: 4766

its easy math
its like in very simplified explainer(very dumbed down)
max number -1 vs min number of +1= cancel each other out to same result

its not like the guy brute forced numbers for centuries. its just basic maths of knowing how the generator point is made
thus not a true collision

odolvlobo

legendary

Activity: 4466

Merit: 3391

Quote from: Jason Brendon on January 19, 2023, 01:57:42 AM

Found a nice pubkey collision with SECP256K1

0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140
and
0x0000000000000000000000000000000000000000000000000000000000000001

That is false.

The public key for the first is 0479BE667...16F81798B7C5258...04EF2777

The public key for the second is 0479BE667...16F81798483ADA77...FB10D4B8

The compressed public keys are also different. One is 0279BE667...16F81798 and the other is 0379BE667...16F81798

Also as noted by @Prime9973 (although he should clarify that he means the x coordinate and not the entire public key)

Quote from: https://twitter.com/Prime9973/status/1609562498499330049

Any two privKey's that sum to the order 'n' of the generator point 'G' will have same pubKey (0n for SECP256K1 = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
If you know 1 privKey, you know the other.

hatshepsut93

legendary

Activity: 3024

Merit: 2148

Quote from: Jason Brendon on January 19, 2023, 01:57:42 AM

was it that easy? Your opinions here.

Quote from: Rijndael@rot13maxi

Not surprising! The first key is the order of G (the generator point) minus 1. And the other one is 1. What happens when you “multiply” 1 by G? You get G. Which is your pubkey

your pibkey there is the x only coordinate of the generator point of secp256k1

Sounds like the author just constructed a pair of keys that collide, rather than taking a random public key and finding a collision through some algorithm, which would have been pretty bad. Basically this is just FUD to scare noobs.

crwth

copper member

Activity: 2940

Merit: 1280

https://linktr.ee/crwthopia

That is only with the pubkey right? This would be fine since it's pub keys.

It's a nice find too. Is this the first time ever?

Jason Brendon

member

Activity: 162

Merit: 65

was it that easy? Your opinions here.

Source: https://twitter.com/PortlandHODL/status/1609113255477407748

Found a nice pubkey collision with SECP256K1

0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140

and

0x0000000000000000000000000000000000000000000000000000000000000001

Give the same pubkey of

79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

Topic: Found a nice pubkey collision (Read 177 times)