Add compressed and uncompressed pub key search

[Coinpiet]

Hello

Is it possible to add a compressed and uncompressed pub key search i think it will increase also the speed.

Set up Brute Force to search only the "X" value from the Pub Key or both "X" and "Y".

That is in the place of Bitcoin Addresses, use only the compressed or uncompressed PubKey.

[dem10]

There are functions to search for compressed and uncompressed private keys.By default, the program looks for compressed keys - here the speed is higher.If you know that the address is compressed and look for the compressed key.

[brichard19]

I think he means skipping the address generation step (hashing public key to address) and comparing the public key directly.

The thing is, if you know the public key already, then there are faster attacks than brute force i.e. Pollard's Rho and Baby-step-giant-step.

So I don't see the point in adding such a feature.

[Coinpiet]

brichard you are right.

yeah this is right but i think most newbie people cant do anything with this algorythms so i thought it is much easier for them to use it here for brute force.

[Coinpiet]

and for this methods we need the exact bit space or not ?

[Coinpiet]

for example for this compressed address: 1EVzaFkkNNXq6RJh2oywwJMn8JPiq8ikDi

compressed pubkey: 0370a6911bcd79991cbf5e12e76b6c203d8b25acbcc143a9a6622ba3e29327426d

and uncompressed address: 17rytd1mF7ZTy8H5uQW1amTpj2wutNc22N

uncompressed pub key: 0470a6911bcd79991cbf5e12e76b6c203d8b25acbcc143a9a6622ba3e29327426dcc597838420593c744d33d1d24dccf9f87344bbb63ac0e18ac6374a5e9cdf6ef

so but i cant do anything with it.

[dem10]

you will not be able to understand whether the compressed address.

[Coinpiet]

what do you mean ?

[PsyShark]

His question is this: 1C4LaM39hsQePVXCpj11EY8guYFjuv53AR 1DsMDoMr5PNVQar1SoUUWWG6oQTg2MHjP7 1DBfqsdT9MSortmgiTEbhxsRUwKXyX2Vnn Determine where uncompressed and where compressed address

[Coinpiet]

Yeah ok but when I have a list with only uncompressed pubkeys it should only calculate the uncompressed address. When you look at blockchain.info for the uncompressed addresses there are only uncompressed public keys so mabey a Funktion for the code that calculate only uncompressed when you choose it.

And only when we find a collision the Programm should calculate the address

[Coinpiet]

I don't search for addresses then. I search only for pubkeys and when a collision I know it if I used a compressed pubkey.List or a uncompressed one.

Please tell me if I understand something wrong

[Coinpiet]

@brichard19

Is it really useless to add that?

[SatoshiNakamotoBitcoins]

@Coinpiet When you know the Public key; and I mean uncompressed, so the X and the Y value are known.

This thread will be your best guess...unfortunately the script runs ons CPU and not on GPU...so first there must be a bit of CUDA magic...;-)

https://github.com/qubd/mini_ecdsa

[MalRekkie]

I think he means skipping the address generation step (hashing public key to address) and comparing the public key directly.

The thing is, if you know the public key already, then there are faster attacks than brute force i.e. Pollard's Rho and Baby-step-giant-step.

So I don't see the point in adding such a feature.

sir why dont u help me on my post 1st as i posted 1st?

the app dont match my HEX with my adresses , it just passes it????

[Coinpiet]

@SatoshiNakamotoBitcoins

Yeah but @brichard19 have code a also something for Cuda. https://github.com/brichard19/ecdl

But how to use with a list of uncompressed pub keys?

[SatoshiNakamotoBitcoins]

@Coinpiet thnx our teacher @brichard19 has done some CUDA magic we can see...the problem is that Bitcoin is on the secp256k1 curve...and isn't feasible...so the so called "Discret Logarithm Problem" can't be solved on this 256 bits Elliptic Curve...

You can read this:

https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/

And this phrase is important to now:

Pollard's ρ in practice

We said that baby-step giant-step can't be used in practice, because of the huge memory requirements. Pollard's rho, on the other hand, requires very few memory. So, how practical is it?

Certicom launched a challenge in 1998 to compute discrete logarithms on elliptic curves with bit lengths ranging from 109 to 359. As of today, only 109-bit long curves have been successfully broken. The latest successful attempt was made in 2004. Quoting Wikipedia:

The prize was awarded on 8 April 2004 to a group of about 2600 people represented by Chris Monico. They also used a version of a parallelized Pollard rho method, taking 17 months of calendar time.

As we have already said, prime192v1 is one of the "smallest" elliptic curves. We also said that Pollard's rho has O(n√) time complexity. If we used the same technique as Chris Monico (the same algorithm, on the same hardware, with the same number of machines), how much would it take to compute a logarithm on prime192v1? 17 months ×2192−−−√2109−−−√≈5⋅1013 months

This number is pretty self-explanatory and gives a clear idea of how hard it can be to break a discrete logarithm using such techniques.

It will be feasible with a Quantum Computer...but this can be solved to move Bitcoin in the futher to a secp384k1 EC or even a secp512k1 EC

Cheers mate...

[SatoshiNakamotoBitcoins]

@Coinpiet @brichard19

For now the best option is to put a 8 GPU rig to work...with a GPU I mean a GTX-1080Ti (CUDA is superior to Opencl...performance wise and reliability)

The best way to this is a combination of randomness and Incremntal search; brichard19 does an excellent job on the Incremental search part and for the randomnesss part there is another repository...https://github.com/Harold-Glitch/bitreverse (but this one...needs a remote connection...I don't like that...;-))

I've mentioned before in this repository that we need the script of brichard19 but altered with some randomness....for example a blocksearch of 1.000.000.000 (this has to be adjustable for custom use)

Bitcoin PrivateKey generation is a random process...you only can defeat this with randomness (and luck...;-))...but combined with a thorough block search.

This "reversed Bitcoin mining" is TOP sport....so why we aim for Bronze and not for Gold??

Do you take the challenge??

Cheers...

[Coinpiet]

@brichard19 please add the public key search i have a file with 14mio compressed pub keys

[SatoshiNakamotoBitcoins]

@MalRekkie What was your question mate??

There are known issues on Intel devices, and ofcourse it's important to use flag -c for compressed and -u for uncompressed addresses...

[MalRekkie]

@MalRekkie What was your question mate??

There are known issues on Intel devices, and ofcourse it's important to use flag -c for compressed and -u for uncompressed addresses...

my AMD dont match keys :( ....AND if i set a custom HEX to start on --continue file it start everytime on same spot..it dont wite a new NEXT file :(

[SatoshiNakamotoBitcoins]

@MalRekkie thnx for your reply...that's a good question...where the dev @brichard19 maybe can give an answer to...

[natedawg469]

@Coinpiet, your pub key search is not relevant. It would serve no useful purpose, cant do much with the publicly known addresses, lol thats the whole purpose of bitcoin. Were searching for the private keys of addresses in the puzzle.

[Coinpiet]

@natedawg469 Of course it will increase the speed when we found matching priv key to a pub key in the list. The step for create the address makes that slower when we have a list with only pub keys and search for the priv keys it will be faster. Or am I wrong?