How? ...
C/C++/Python and most of the other 'commonly' known languages are readily available in CentOS/Ubuntu. How is PureBasic one of those and how on earth do you compile this in a CentOS7/8 VPS.
I suppose it is one thing to say it works, another to make it work in such environments. Windows will never be an OS we use.
So if you can point to a link that shows how to compile this in CentOS/Ubuntu - I may be able to work it out without taking any of my developers off the projects they are already inundated with.
#crysx
C/C++/Python and most of the other 'commonly' known languages are readily available in CentOS/Ubuntu. How is PureBasic one of those and how on earth do you compile this in a CentOS7/8 VPS.
I suppose it is one thing to say it works, another to make it work in such environments. Windows will never be an OS we use.
So if you can point to a link that shows how to compile this in CentOS/Ubuntu - I may be able to work it out without taking any of my developers off the projects they are already inundated with.
#crysx
If you're referring to Bitcrack itself and not a pool, it's pretty straight forward: make BUILD_CUDA=1
Memory usage during compilation is actually very light, should work on an entry-level VPS. I suspect this is not what you're asking though. I'm quite confused.
Original VanitySearch uses endomorphisms to perform fast additional checks for each key generated.
For each key it checks K, K*lambda, K*lambda*lambda, -K, -K*lambda, -K*lambda*lambda - total 6 possible addresses.
For each key it checks K, K*lambda, K*lambda*lambda, -K, -K*lambda, -K*lambda*lambda - total 6 possible addresses.
Now I know what an endomorphism is. By sheer coincidence, I was thinking about implementing something like:
Code:
x.bits64[0] == key.bits64[0] && ...
~x.bits64[0] == key.bits64[0] && ...
... 14 more lines
So I would've checked 15 other keys just by flipping each of the 4 64-bit words that make up the Int using NOT, but in the end I scrapped it because I didn't think any of those additional points have any special relationship with the target public key.
I have no idea either...no way to write 15 billion in one minute, IMO, at least not on my hardware. Best I could do was about 200K a minute. Let me better explain. Normally when I do a search/look for keys, whether random or sequential, one of my GPUs will get 200MKey/s, but when I try to write the results, it drops to 0.1MKey/s because of the writing to file/RAM. So the bottleneck to me, is all in the CPU writing to file.
Alternatively if you have a 10GBit Ethernet port lying around somewhere you can just send all the points across your local network to some other system that just writes the points in its own storage.
The idea scales too: While the other system is waiting on packets it can send some more points to other systems so that it doesn't have to write all the points on its own disk and fill it up quickly. There are some kernel options that tune the network drivers for uploading.
Pool ...
I do know how to compile and such basic levels, just not a coder. I am referrign to the Pool link that apparently runs the BitCrack Software (and forks thereof) in a pooled environment. PureBasic is apparently what it is written in, and unlike any other compilations that I have created to date, this is not one I am familiar with.
An open source and available Pool is something I am happy to setup for the community, including the vast array of GPU systems IF deemed necessary to work with, that we have at our disposal also.
I am happy to work WITH someone along the lines of setting up under CentOS7/8 and my appreciation would go further than just a 'Thanks'. Purely because I like dabbling with things that interest the hell outta me
#crysx
