Pages:
Author

Topic: BitCrack - A tool for brute-forcing private keys - page 63. (Read 76850 times)

jr. member
Activity: 114
Merit: 5
Hello guys,
Is there a way to stop the work and continue later at this point?




Holy crap thats some setup you have going! that's like what 4-5 v100s?

But anyway, if you want to save the point to start again later you can take the number in the brackets, in your example  the number would be 812,819,340,591,104 and covert that from decimal into hexadecimal here: https://brainwalletx.github.io/#converter which in the example would output 02e34140100000, you would just use that as your keyspace start point next time you want to run it.

It looks to me though that you are trying to crack a single address by running through the entire 2^160 keyspace? Would you not be better off trying to crack challenge address #120 with pollard kangaroo software? https://github.com/JeanLucPons/Kangaroo
newbie
Activity: 3
Merit: 0
Hello guys,
Is there a way to stop the work and continue later at this point?


https://i.imgur.com/bAiYIFc.jpg
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
So NVIDIA just nerfed their new GPUs for mining: https://www.xda-developers.com/nvidia-cmp-cryptocurrency-mining-processor/amp/ says that ethereum hashrate on the 3060 has been nerfed by 50% by some firmware inside the GPU that eerily reminds me of hardware-based DRM.

What effect do you think this will have on the speed of Bitcrack and friends? (Yes I know Bitcrack doesn't even work on RTX 30, I am working with someone right now to lease a Tesla GPU from AWS which should be finished one of these days so I can finally start thrashing that monster bug  Smiley)

It looks like they are detecting if certain hashing functions are being used in CUDA but I'm not sure which. How do they do that anyway, since there is no builtin SHA or elliptic curve or RIPEMD160 libraries in CUDA and these all are user-written?



In other news they're also releasing a GPU-as-a-miner kind of card. I wonder if Bitcrack will work on those without modifications or if these can only mine Ethereum.
jr. member
Activity: 36
Merit: 3
My base logic is always, if someone would know/got a better way, why would you sell it. There is enough puzzle bitcoins for grabs if the tool would be real.

Edit:
Ah, his tool is a database of wallets + pub keys.
See https://bitcointalksearch.org/topic/--5307531
full member
Activity: 1162
Merit: 237
Shooters Shoot...
How do you know that what you see is a real result of calculations, not just a movie?
I'm not sure what it is even doing/showing....calculating the pubkey via binary to hex?
I will make one as well, will anyone be interested in buying it? I will sell it for half of what he is selling for  Grin
jr. member
Activity: 114
Merit: 5
Yo why is anyone here talking about buying or selling software when JeanLucPons has already released open-source GPU kangaroo software?

https://github.com/JeanLucPons/Kangaroo
full member
Activity: 706
Merit: 111


It seems like a good program that we all could put some use to. I see he was charging at least $50k for this a year ago.
legendary
Activity: 952
Merit: 1385
How do you know that what you see is a real result of calculations, not just a movie?
full member
Activity: 431
Merit: 105
me was thinking that same i guess,
would love a program that moves around the cursor positions and tell me where the right
one should go to.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org

you again posting link to your own ecdsa supra ? [email protected]

ok you smart. got a program many want. 50k now 20k on satoshidisk.
just figured that one out?

i asked if like many could get a copy. but hey who's nice.
 Shocked

Yeah, I just watched the video and from reading that satoshidisk link it looks like he's trying to sell it for 0.26BTC. I also took a screenshot of the video:



If you look closely at the top you can see that he's running a PHP script from Linux or MAC, that connects to Google BigQuery (a cloud computing service) to run it's brute forcing. This raises another red flag, since by paying this guy $10K you get a script that can become worthless if he shuts off the cloud computing services and optionally runs another instance of the service at some other IP address. Which is a shame because it actually looks like a promising tool, which can search more than 160 bits space (I'm guessing the "61 160" at the top right is the bit range).
full member
Activity: 431
Merit: 105

you again posting link to your own ecdsa supra ? [email protected]

ok you smart. got a program many want. 50k now 20k on satoshidisk.
just figured that one out?

i asked if like many could get a copy. but hey who's nice.
 Shocked
member
Activity: 255
Merit: 27
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
secp256k1::uint256 CLKeySearchDevice::getNextKey()
{
    uint64_t totalPoints = (uint64_t)_points * _threads * _blocks;

    return _start + secp256k1::uint256(totalPoints) * _iterations * _stride;
}

Can I add some creative counting to the function? For example, ×2 private key, ×3 private key, or using fibonacci sequence.


The value of _start + secp256k1::uint256(totalPoints) * _iterations * _stride is going to be the next private key so if what you are trying to accomplish is to "skip over" private keys, multiply this result by whatever value you want to use (except you shouldn't multiply _start with this number), and pass an additional argument to getNextKey() that is a pointer to struct that contains the next number in the sequence to multiply by. Perhaps also include in there a number that the limit to the number of terms in the sequence to use, after which it wraps around.

You could even make this number a modulus for excessively large sequence terms to be divided into.

Code:
typedef struct nextkey_state {
    uint64_t index;
    uint64_t limit; // or uint64_t modulus
} nextkey_state_t;

secp256k1::uint256 CLKeySearchDevice::getNextKey(nextkey_state_t *state)
{
  // ...
}

And then of course update all function calls to use this parameter.
newbie
Activity: 19
Merit: 2
secp256k1::uint256 CLKeySearchDevice::getNextKey()
{
    uint64_t totalPoints = (uint64_t)_points * _threads * _blocks;

    return _start + secp256k1::uint256(totalPoints) * _iterations * _stride;
}

Can I add some creative counting to the function? For example, ×2 private key, ×3 private key, or using fibonacci sequence.
full member
Activity: 706
Merit: 111
Most likely there will have to be another program to be made to solve the remaining keys left between #64 - #160. I don't see bitcrack solving no more keys, its no longer getting the job done.
newbie
Activity: 2
Merit: 0
Quote


Unable to open 'address.txt'
Can you help me out pls.
if you are using exact commands from above, the address list was titled "-i addresses.txt" (addresses, not address) but whatever the file you have your addresses in, that's what you need to specify using the -i command. Example, if your addresses are stored in apple.txt document, then you would use
-i apple.txt
That was spelling mistake, I do the same
Here's is link image
https://imgur.com/dkx89mc
https://imgur.com/oMf6XCc
newbie
Activity: 18
Merit: 1
one cuda coder bitcoinforktech disapear from 21 jan 2021, anyone know where he go, hope he will be fine, not infected by covid19, if anyone know write here about him for not online from 21 jan

https://bitcointalksearch.org/user/bitcoinforktech-2863059


thankx God, found he is live and maybe busy in dome project, as his listed bitcoin address in his profile
bc1qthrhmdmfawq6w4lzmjrce3reuxt06pvvnhpkj6

used on 5th feb 2021, receive and send
indicate he is live and getting his money for his work/assignments


So, basically, all the remaining puzzle problems become really hard or not rewarding enough. So, most developers are working on some other projects. On kangaroo readme it is mentioned 120 puzzle would take 2 months on 256 v100s to find a solution. I think 64 problem is also similarly hard. So, not much to do here unless the original puzzle maker adds more to the wallets again...

Making outgoing transactions on 70-120 wallets is also one way. But would be cleaned by people who have good experience with running kangaroo and good hardware resources... Until then no progress further. A lotta resources went in 64 and 120, so they might get cracked. After that no hopes...
member
Activity: 330
Merit: 34
one cuda coder bitcoinforktech disapear from 21 jan 2021, anyone know where he go, hope he will be fine, not infected by covid19, if anyone know write here about him for not online from 21 jan

https://bitcointalksearch.org/user/bitcoinforktech-2863059


thankx God, found he is live and maybe busy in dome project, as his listed bitcoin address in his profile
bc1qthrhmdmfawq6w4lzmjrce3reuxt06pvvnhpkj6

used on 5th feb 2021, receive and send
indicate he is live and getting his money for his work/assignments
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
Ohh I see. So, let's say we want to search 64 bit space, we can do that with bitcrack as usual. But with vanitysearch it doesn't make sense as it searches 6 points at a time and most probably 5 of them are out of that 64 bit space, right? Makes sense. Thanks for explanation.

Also, what makes these so fast than official implementation? It is kinda mind boggling to think someone can do 1000/10k times better than usual implementation. (Right from vanitygen, they all have very amazing perf.) Any links to docs or papers is fine. Thanks in advance.
Right, some keys will be out of the 64 bit range with VanitySearch and all keys will be in specified range with BitCrack.

What do you mean when you say "so fast than official implementation?"
newbie
Activity: 18
Merit: 1
Also I was getting 1000mk/s on 1080ti on vanity search but only 300mk/s on bitcrack. What is this that slow? As far as I know vanity search only have to compare first 4-6 characters and this has to compare whole address. Is that the only reason for this slowness or something else in the implementation?

I can't help you choose parameters because I don't have any of those, still trying to find a way to lease a GPU for bitcoin (turns out it's very hard to find someone who's not trying to sell you a miner  Undecided). But the reason why VanitySearch is much faster than this is not related to the number of characters they are comparing, it's due to the fact that Jean_Luc's code generates a "jump table" of secp256k1 points (see e.g. GPU/Group.h) so he avoids actually doing the elliptic curve math at runtime, unlike brichard's code. This is despite both their engines being written in CUDA.

In VanitySearch he also writes all his math in assembly code while Bitcrack uses C for its math functions.

Several pages back somebody posted here that they used -b 112 -t 512 -p 512 for their 1080 and got similar speeds as you.

BTW, kinda offtopic. My python implementation (<50 lines) using external libs is doing only 100 keys/sec (on single cpu core) and also I noticed official c/python implementations also do around 1000 keys/sec while generating. What makes these generators a thousand/million times faster? Is it just a simple trick or years worth of dev? Give some pointers maybe.

Are your python files compiled? Try doing that so that your code doesn't have to be interpreted at runtime, using python -m compileall YOUR_PY_FILES.

Also while running on windows, it is not showing any cpu/gpu/memory. Why is that?

What do you mean? Bitcrack never printed how much CPU or memory it uses in the console. Do you mean in Task Manager? If so then you'll usually find it as a child process of Windows Command Processor (and Task Manager is going to show that using a lot of resources but it's actually the child process running inside it using all that).
You also have to realize, VanitySearch is searching more than just Point. It is searching Point +  endo1 + endo2 + symmetry ( pt.y.ModNeg; p1.y.ModNeg; and p2.y.ModNeg; It's a different animal than Bitcrack, hence what seems like super speed compared to Bitcrack. Just different designs and purposes. One is point by point the other is 6 points.

Ohh I see. So, let's say we want to search 64 bit space, we can do that with bitcrack as usual. But with vanitysearch it doesn't make sense as it searches 6 points at a time and most probably 5 of them are out of that 64 bit space, right? Makes sense. Thanks for explanation.

Also, what makes these so fast than official implementation? It is kinda mind boggling to think someone can do 1000/10k times better than usual implementation. (Right from vanitygen, they all have very amazing perf.) Any links to docs or papers is fine. Thanks in advance.
Pages:
Jump to: