Re: Large Bitcoin Collider (Collision Finders Pool)
Advertised sites are not endorsed by the bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Jr. Member Offline
Activity: 49
@rico666 “….Because we assume the private keys to addresses with funds on them are also uniformly distributed in the search space, this means that the effective search space until any collision for these is found is 160bit – log2(9000000)bit = ~137bit.”
I might be wrong, but because of this (wolfram alpha expression):
1-(((2^21)! * (2^160 über 2^21))/((2^160)^(2^21)))
I’m not sure I follow this. (mathematically I do, but semantically I don’t)
Where do you get the 221 from? Thats 2M.
I assume the possibilty of hitting one of your approximately 2,5 mil target addresses is: 1.5*10^-36 or 1/(2^119)
We have 14 mil target addresses at the moment.
If you agree with the things written above, I would recommend to expand the target address space to 2^23 (8.x mil pub keys) and gain a 4 times higher possibility to hit one of your targets: 2.4*10^-35 or or 1/(2^115)
It’s still 160 – log2(14000000) = ~ 136.26bit search space
Rico
Hello Rico,
what I wanted to submit was that in terms of prohability you should consider to expand your public address list for comparision from about 2.x million to 8.y million pub keys. I have read somewhere, maybe in some older postings, that your address list covers only 2.5 million addresses. As you know the birthday paradox () says with an increasing number of persons (in our example: public addresses) the prohability to find 2 with the same birthdays (in our example: RIPEMD-160 hash number) increases exponentially.
2 million addesses give us a prohability of: 1-(((2^21)! * (2^160 über 2^21))/((2^160)^(2^21))) = 1.504 × 10^-36 or differently: 1-e^((-2^21*(2^21-1))/(2*2^160)) = 1.504 × 10^-36
8 million addesses give us a prohability of: 1-e^((-2^23*(2^23-1))/(2*2^160)) =2.407 × 10^-35
4 times more public addresses give a 16 times higher prohability to hit one target. That´s why I suggested to expand the public key address space. Want I did not know at the time of writing that you already expand your list to 14 million addresses.
So your prohability with 14 million addresses for each key you are generating at the moment is about: 1-e^((-2^23.7389*(2^23.7389-1))/(2*2^160)) = 6.70521 × 10^-35 or simpler as we have big numbers: (2^23.7389)^2/(2*2^160) = 6.70521 × 10^-35
Besides that, I came across an interessting article about increasing the prohability of collision through interating hash functions:
and
N(hash1)>N(hash2)>N(hash3)>N(hash4)….>N(hashx) due to collisions and the lacking to use the full 256 rsp. 160 bit space. 4 hashes have to be done to create a bitcoin address. This is surely reducing the number of different pub addresses further. The collisions and mapping errors of each hash level causing an exponential effect in reducing the output. That is giving you a better prohability than 6.70521 × 10^-35.
Reagrds, Janu$$
I see the client is created in perl, will there be support for windows? strawberry perl or such.
An ISO Live Image may be good for people who have a GPU and are not running linux.
Cuda and OCL?
At the moment an easy-to-use ISO for windows users would be the best option (in any case for the GPU client, but also welcome for the CPU client).
The generator is written in C/OpenCL. As for a native windows client: The Perl client (LBC) is not the problem (it does run on Strawberry and we had a windows version already – the source still has rudimentary support for it in it’s DNA), the problem is the generator using some libc memory management intrinsics.
=> I would happily give GPUauth=1 to anybody who would do a decent easy-to-use robust GPU (Nvidia and AMD) and CPU support LBC image ISO.
Of course it would still have to go through a rigorous review process for trojans/viruses etc. but I believe it would be a very welcome addition for the Win-users with nifty GPUs.
Ideally, it would be a minimal Linux which would boot from USB stick. As for “live-image” – LBC does auto-update itself (BLF, generator and the LBC itself), so there should be a writable partition on the USB stick else people would have to load a new version of the ISO over and over again. (and I wouldn’t have the time to review the images that often – thus not authorize them)
Rico
edit: I see you all left the #666 post for me – how nice of you.
all non self-referential signatures except mine are lame … oh wait … · Behold! Your maximum speed is 5553734 keys/s per CPU core.
I see the client is created in perl, will there be support for windows? strawberry perl or such.
An ISO Live Image may be good for people who have a GPU and are not running linux.
Cuda and OCL?
At the moment an easy-to-use ISO for windows users would be the best option (in any case for the GPU client, but also welcome for the CPU client).
The generator is written in C/OpenCL. As for a native windows client: The Perl client (LBC) is not the problem (it does run on Strawberry and we had a windows version already – the source still has rudimentary support for it in it’s DNA), the problem is the generator using some libc memory management intrinsics.
=> I would happily give GPUauth=1 to anybody who would do a decent easy-to-use robust GPU (Nvidia and AMD) and CPU support LBC image ISO.
Of course it would still have to go through a rigorous review process for trojans/viruses etc. but I believe it would be a very welcome addition for the Win-users with nifty GPUs.
Ideally, it would be a minimal Linux which would boot from USB stick. As for “live-image” – LBC does auto-update itself (BLF, generator and the LBC itself), so there should be a writable partition on the USB stick else people would have to load a new version of the ISO over and over again. (and I wouldn’t have the time to review the images that often – thus not authorize them)
Rico
I can have a look at this as I have a fair bit of experience with linux and arch seems a good use for this. dont worry about the gpuauth=1 yet, il see if I can get an iso up and running with the client and right dependencies installed first and then I can get back to you on that. Also being arch and minimal it will be easier to go over for the review process.
I also have a fair bit of time on my hands at the moment, so it may do me some good
Legendary Offline
Activity: 1090
So your prohability with 14 million addresses for each key you are generating at the moment is about: 1-e^((-2^23.7389*(2^23.7389-1))/(2*2^160)) = 6.70521 × 10^-35 or simpler as we have big numbers: (2^23.7389)^2/(2*2^160) = 6.70521 × 10^-35
Interesting. I thought the probability is 1/2(160-23.7389) = ~ 9.52 x 10-42
Now I am at the moment in the middle of the rollout of the new client, so I cannot dig deeper into this, but I will certainly have a look for the explanation of this 7 orders of magnitude discrepancy.
Thanks!
Rico
This revelation is of equal, if not greater, significance to Alan Guth’s discovery in 1979 of the exponential expansion of the universe, doubling in size 100 times for 10-35 seconds right after the Big Bang.
An instant 7-magnitude increase in the bitcoin Big Banger, in one post! This should win the Nobel Cryptocurrency Prize.
I put Satoshi on “ignore”.
Hi colliders!
New versions of the SSE42, AVX2 and Skylake hrd-core generators are now available. These use the arulbero-ECC library instead of the libsecp256k1 and give a nice keyrate bump. It’s not as big as for the GPU-accelerated versions (soon to come), but still pretty decent. It seems the sse42 version profits most.
SSE42: +79% AVX2: +29% Skylake: +6%
There will be no SSE41 or 32bit-generic versions available. If you run one of these, put a "no_update": 1, line in your lbc.json. edit: but there will be a 64bit generic binary available!
How to update?
1) End your LBC by pressing “e” and wait until you see the shell prompt.
2) type in ./LBC -u, it will update the generator (and may even the BLF)
# LBC -u New generator found. (DL-size: 0.54MB) BLF patch found. (DL-size: 206.96MB) Finished update run – system up to date.
3) type in ./LBC -x to test and benchmark the new generator. You should see a better maximum keyrate.
4) Ready to go!
Rico
all non self-referential signatures except mine are lame … oh wait … · Behold! Your maximum speed is 5553734 keys/s per CPU core.
Newbie Offline
Activity: 20
ubuntu@instance-5:~/collider$ ./LBC -u Finished update run – system up to date.
ubuntu@instance-5:~/collider$ ./LBC -x Testing mode. Using page 0, turning off looping. Benchmark info not found – benchmarking… done. Your maximum speed is 511909 keys/s per CPU core.
Nothing happens
But …
Ask for work… got blocks [1466349440-1466357631] (8589 Mkeys)
went to
Ask for work… got blocks [1466443152-1466452879] (10200 Mkeys)
I think it did update somehow.
tried with sudo ./LBC -u nothing happens.
ubuntu@instance-5:~/collider$ ./LBC -u Finished update run – system up to date.
ubuntu@instance-5:~/collider$ ./LBC -x Testing mode. Using page 0, turning off looping. Benchmark info not found – benchmarking… done. Your maximum speed is 511909 keys/s per CPU core.
Nothing happens
But …
Ask for work… got blocks [1466349440-1466357631] (8589 Mkeys)
went to
Ask for work… got blocks [1466443152-1466452879] (10200 Mkeys)
I think it did update somehow. [/quote]
If there was an output after LBC -u (new generator found) yes. Else: no
LBC -u must fetch a new generator. If it doesn’t (for whatever reasons), you must fetch it manually (unpack, rename, chmod a+x, yadda yadda)
then LBC -x, then profit
Rico
all non self-referential signatures except mine are lame … oh wait … · Behold! Your maximum speed is 5553734 keys/s per CPU core.
Newbie Offline
Activity: 20
I believe these 4 x K80 machines could still deliver more than 70 Mkeys/s each (machine).
What about 32 vCPU , 8 x K80 machines ?
Published at Tue, 28 Mar 2017 03:06:01 +0000
[wpr5_ebay kw=”bitcoin” num=”1″ ebcat=”” cid=”5338043562″ lang=”en-US” country=”0″ sort=”bestmatch”] If you enjoy my photos, you are welcome to #donate #bitcoin to me at: 1Q2LV3bsxZjRBQoRXAXikpUGPCrNeGSUWc By antwerpenR on 2013-07-20 12:23:26
White shoe investment bank Goldman Sachs has had outsized influence on Wall Street and in government for years. The influential company now says bitcoin and other digital currencies are real money. #BREAKING NEWS
News – CCN SEC’s New Fintech Hub Helps Blockchain Startups Navigate ICO Rules The U.S. Securities and Exchange Commission (SEC) announced today the launch of a “New Strategic Hub for Innovation and Financial Technology.” In a surprising […]
