Bitcoin Forum
February 21, 2019, 03:24:39 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
Author Topic: Large Bitcoin Collider (Collision Finders Pool)  (Read 167545 times)
Janu$$
Member
**
Offline Offline

Activity: 86
Merit: 10


View Profile
March 26, 2017, 03:48:55 PM
 #661

@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.

Quote
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.

Quote
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 (https://en.wikipedia.org/wiki/Birthday_problem) 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:
https://security.stackexchange.com/questions/61756/wont-all-hashes-collide-after-enough-iterations-with-a-static-salt
and
http://crypto.stackexchange.com/questions/15068/entropy-when-iterating-cryptographic-hash-functions

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$$







1550762679
Hero Member
*
Offline Offline

Posts: 1550762679

View Profile Personal Message (Offline)

Ignore
1550762679
Reply with quote  #2

1550762679
Report to moderator
1550762679
Hero Member
*
Offline Offline

Posts: 1550762679

View Profile Personal Message (Offline)

Ignore
1550762679
Reply with quote  #2

1550762679
Report to moderator
1550762679
Hero Member
*
Offline Offline

Posts: 1550762679

View Profile Personal Message (Offline)

Ignore
1550762679
Reply with quote  #2

1550762679
Report to moderator
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550762679
Hero Member
*
Offline Offline

Posts: 1550762679

View Profile Personal Message (Offline)

Ignore
1550762679
Reply with quote  #2

1550762679
Report to moderator
1550762679
Hero Member
*
Offline Offline

Posts: 1550762679

View Profile Personal Message (Offline)

Ignore
1550762679
Reply with quote  #2

1550762679
Report to moderator
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
March 26, 2017, 04:19:57 PM
 #662

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
icanscript
Hero Member
*****
Offline Offline

Activity: 700
Merit: 502



View Profile
March 26, 2017, 04:45:26 PM
 #663

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?
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
March 26, 2017, 05:35:00 PM
Last edit: March 26, 2017, 06:00:42 PM by rico666
 #664

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.  Wink

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 ...   ·  LBC Thread (News)  ·  BURST Activities
icanscript
Hero Member
*****
Offline Offline

Activity: 700
Merit: 502



View Profile
March 26, 2017, 05:39:14 PM
 #665

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.  Wink

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 Smiley
TooDumbForBitcoin
Legendary
*
Offline Offline

Activity: 1610
Merit: 1001


best digital asset exchange


View Profile
March 26, 2017, 05:41:49 PM
 #666

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.

          ██
          ███
          ████
         ██████
        ▄███████
       ▄████████
      ▄█████████
     ██████████
    ██████████    ██
   ██████████     ███
  ██████████     █████
 ██████████     ██████▄
 █████████     ████████
█████████     █████████
████████     ██████████
████████    ███████████
 ███████    ██████████
  ██████    █████████
   ▀█████    ██████▀
     ▀▀███    ██▀▀
 
Huobi Russia
 

|
  Exchange Trading
OTC / Mining pool
Listing new projects
Innovations Development
  High Security / Support 24/7
Special security for traders
App for IOS and Android
Dedicated high-speed API
 

|
 
.PRIVATE SALE.
STARTS 10.12.2018
 
.PUBLIC SALE.
STARTS 08.04.2019
   

|
  ENG| RU ● ●  ———
ANN THREAD
  FACEBOOK
REDDIT
TELEGRAM
TWITTER
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
March 27, 2017, 07:05:20 AM
Last edit: March 27, 2017, 09:15:58 AM by rico666
 #667

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)

Code:
# 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 ...   ·  LBC Thread (News)  ·  BURST Activities
unknownhostname
Member
**
Offline Offline

Activity: 61
Merit: 10


View Profile
March 27, 2017, 11:44:26 AM
Last edit: March 27, 2017, 12:23:31 PM by unknownhostname
 #668

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.

rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
March 27, 2017, 12:13:10 PM
 #669

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 ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
March 27, 2017, 12:18:17 PM
 #670

It's official, the on-GPU bloom filter code is not working on Nvidia Tesla K80.  Angry

To be more precise, it's the simple single "printf" that's crashing the app.
The one single printf which shows - on rare occasions - a find. e.g.

Code:
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001 + 0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001 + 0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001 + 0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001 + 0xf8c

I will probably make the on-GPU bloom selectable by command line option to navigate around this problem. Until then, if you have a K80 (which unfortunately is true for most of the cloud machines), the old GPU gnerator is working...
If you have newer machines like Maxwell or Pascal architectures and a Nvidia 375 or newer driver, chances are very good it will work for you. On the other hand, its quite probable if you have a Kepler GPU (or older), that the new code will bite you.


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
unknownhostname
Member
**
Offline Offline

Activity: 61
Merit: 10


View Profile
March 27, 2017, 12:34:34 PM
 #671

It's official, the on-GPU bloom filter code is not working on Nvidia Tesla K80.  Angry


So what do u want me to put on those GPU k80 servers ?
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
March 27, 2017, 12:37:44 PM
 #672

It's official, the on-GPU bloom filter code is not working on Nvidia Tesla K80.  Angry


So what do u want me to put on those GPU k80 servers ?

The new version I will write especially for these servers. It's PITA, but it would be a shame to not have a keyrate doubling.
So wait for it (1-2 days). I believe these 4 x K80 machines could still deliver more than 70 Mkeys/s each (machine).

Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
unknownhostname
Member
**
Offline Offline

Activity: 61
Merit: 10


View Profile
March 27, 2017, 02:21:29 PM
 #673

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 ?
rico666
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
March 27, 2017, 03:54:39 PM
 #674

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 ?

I believe the 8 x K80 machines do have 64 vCPU? else even the new generator cannot saturate 8 K80 with "only" 32 vCPUs.
Still, the speedup and GPU usage is way better with the new GPU generators. Speedup between 2.5x and 3.1x is to be expected.
With the 4 x K80 32vCPU machines one can expect the CPUs to almost saturate the GPUs. (Now less than 50%)

All in all - with the new generators we should be able to significantly lower the time until #51. Even worst case it should be 10 days less than what the stats show now. (edit: I see we have almost 40% of the #51 search space covered)


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
GoldTiger69
Hero Member
*****
Offline Offline

Activity: 518
Merit: 502


View Profile WWW
March 27, 2017, 09:38:28 PM
 #675

I just updated my  LBC and now I'm getting this: Server doesn't like us. Answer: too fast.
I'm using and AMD FX 4300 with ./LBC -c 2 (I even tried -c 1, same result).
Thanks in advance.

I can help you to restore/recover your wallet or password.
https://bitcointalk.org/index.php?topic=1234619.0
Jude Austin
Legendary
*
Offline Offline

Activity: 1139
Merit: 1000


The Real Jude Austin


View Profile WWW
March 28, 2017, 03:06:01 AM
 #676

I just updated my  LBC and now I'm getting this: Server doesn't like us. Answer: too fast.
I'm using and AMD FX 4300 with ./LBC -c 2 (I even tried -c 1, same result).
Thanks in advance.

What generator is LBC trying to use?

Get paid BTC to sign up for free tokens: http://earn.com/judeaustin/referral/?a=d3euriwoffdrlv4b
palawan
Sr. Member
****
Offline Offline

Activity: 386
Merit: 250


View Profile
March 28, 2017, 03:34:45 AM
 #677

.....

Code:
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001 + 0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001 + 0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001 + 0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001 + 0xf8c

...
Rico

Hello, how is the private key converted to normal format?

halu
GoldTiger69
Hero Member
*****
Offline Offline

Activity: 518
Merit: 502


View Profile WWW
March 28, 2017, 04:12:58 AM
 #678

I just updated my  LBC and now I'm getting this: Server doesn't like us. Answer: too fast.
I'm using and AMD FX 4300 with ./LBC -c 2 (I even tried -c 1, same result).
Thanks in advance.

What generator is LBC trying to use?

I see this file there: gen-hrdcore-sse42-linux64

I can help you to restore/recover your wallet or password.
https://bitcointalk.org/index.php?topic=1234619.0
Jude Austin
Legendary
*
Offline Offline

Activity: 1139
Merit: 1000


The Real Jude Austin


View Profile WWW
March 28, 2017, 04:24:13 AM
 #679

I just updated my  LBC and now I'm getting this: Server doesn't like us. Answer: too fast.
I'm using and AMD FX 4300 with ./LBC -c 2 (I even tried -c 1, same result).
Thanks in advance.

What generator is LBC trying to use?

I see this file there: gen-hrdcore-sse42-linux64

Did you try a benchmark test? Append -x and see what happens.

Get paid BTC to sign up for free tokens: http://earn.com/judeaustin/referral/?a=d3euriwoffdrlv4b
GoldTiger69
Hero Member
*****
Offline Offline

Activity: 518
Merit: 502


View Profile WWW
March 28, 2017, 04:44:15 AM
 #680

I just updated my  LBC and now I'm getting this: Server doesn't like us. Answer: too fast.
I'm using and AMD FX 4300 with ./LBC -c 2 (I even tried -c 1, same result).
Thanks in advance.

What generator is LBC trying to use?

I see this file there: gen-hrdcore-sse42-linux64

Did you try a benchmark test? Append -x and see what happens.

This is the result:

./LBC -x
Will use 2 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 3720003547 keys/s per CPU core.

I can help you to restore/recover your wallet or password.
https://bitcointalk.org/index.php?topic=1234619.0
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [34] 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!