Large Bitcoin Collider (Collision Finders Pool)

[TooDumbForBitcoin]

And the 1st 500bn keys (something that took the project like two months) are searched today within 30 minutes.

And we all are going to be dead when 2^256 keys are searched in this project within next couple of centuries.

Get your basics right. This project is not searching 2^256 keys.

Rico

This is fairly high praise coming from a detractor.  Not many 2-century projects in human history. 

[unknownhostname]

And we all are going to be dead when 2^256 keys are searched in this project within next couple of centuries.

There is no need for the 2^256 ...

And I'm sure compute power will get insane in the couple of years.

Rico you should update the trophies page

[rico666]

Rico you should update the trophies page

Done: https://lbc.cryptoguru.org/trophies

As one can see,

#47 -> #48: 1 month
#48 -> #49: 2 months
#49 -> #50: 1 month 

I think that for now, we're fighting combinatorics pretty well.


Rico

[unknownhostname]

Rico you should update the trophies page

Done: https://lbc.cryptoguru.org/trophies

As one can see,

#47 -> #48: 1 month
#48 -> #49: 2 months
#49 -> #50: 1 month  

I think that for now, we're fighting combinatorics pretty well.


Rico

I'll try to get the nr 51 this week ... 1000 + CPU's incoming

[rico666]

I'll try to get the nr 51 this week ... 1000 + CPU's incoming

You're crazy.  
Ok - I try to get a GPU client at least 3x faster than the current one before you find #51.
Challenge accepted? (Odds are I'll lose ... probably)

Rico

[Jude Austin]

Rico you should update the trophies page

Done: https://lbc.cryptoguru.org/trophies

As one can see,

#47 -> #48: 1 month
#48 -> #49: 2 months
#49 -> #50: 1 month  

I think that for now, we're fighting combinatorics pretty well.


Rico

I'll try to get the nr 51 this week ... 1000 + CPU's incoming

Wow...

Botnet?

[unknownhostname]

Wow...

Botnet?

Nop ... just free cloud

[Jude Austin]

Wow...

Botnet?

Nop ... just free cloud

Free cloud, as in I can join in on this fun?

I can haz teh clowd?

[rico666]

I'll try to get the nr 51 this week ... 1000 + CPU's incoming

Exceptionally, I set the pool computational front to 2^50. We will cover the ~370 tn keys after we have found #51.

You will see this on block numbers > 1073770688

The stats about predicted find time for #51 are therefore not correct anymore (because the pool is aware of missing ~370 tn keys).
So you simply have to do some calculation in your head:

If the pool says

the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS (#51 of the puzzle transaction) in N to M days.

it currently means

the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS (#51 of the puzzle transaction) in 0 to M-N days.

Effectively this means, I saved you 14 days or so at current speed. It also means, the find can happen anytime from now to 41 days (current speed).

Good hunting!


Rico

[unknownhostname]

I'll try to get the nr 51 this week ... 1000 + CPU's incoming

Exceptionally, I set the pool computational front to 2^50. We will cover the ~370 tn keys after we have found #51.

You will see this on block numbers > 1073770688

The stats about predicted find time for #51 are therefore not correct anymore (because the pool is aware of missing ~370 tn keys).
So you simply have to do some calculation in your head:

If the pool says

the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS (#51 of the puzzle transaction) in N to M days.

it currently means

the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS (#51 of the puzzle transaction) in 0 to M-N days.

Effectively this means, I saved you 14 days or so at current speed. It also means, the find can happen anytime from now to 41 days (current speed).

Good hunting!


Rico

Yea I know that ... I want to bring the 41 days time to 0

[rico666]

Effectively this means, I saved you 14 days or so at current speed. It also means, the find can happen anytime from now to 41 days (current speed).

Yea I know that ... I want to bring the 41 days time to 0

For this you'd need either immediate luck, or infinite speed.

To have #51 in 1 day under worst case scenario, the pool would need to have about 13.5 GKeys/s


Rico

[unknownhostname]

Exceptionally, I set the pool computational front to 2^50. We will cover the ~370 tn keys after we have found #51.

You will see this on block numbers > 1073770688

Ask for work... got blocks [1080203856-1080210383]

[rico666]

Ask for work... got blocks [1080203856-1080210383]

We have officially searched about 11 tn keys in #51 search space.

Code:

[1087617328, 1087624239] <<<                  Unknownhostname

out of 1125 tn keys so about 1% done


edit: 384 MKeys/s = 3 million pages on directory.io per second

Rico

[unknownhostname]

edit: 384 MKeys/s = 3 million pages on directory.io per second

Rico

The real speed right now is more than 500Mkeys/s I guess.

Ask for work... got blocks [1091773040-1091779951]

[rico666]

edit: 384 MKeys/s = 3 million pages on directory.io per second

Rico

The real speed right now is more than 500Mkeys/s I guess.

Ask for work... got blocks [1091773040-1091779951]

Define "real"

Depends on the averaging time. The stats show a 24h average, The average in the past 1 hour will be higher.
One can estimate this from the gradient af speed growth - we're going straight up with no sign of a slowdown.
So yeah - give it a couple hours and it may show a slowdown at 480+ Mkeys.

512Mkeys = 4 million pages on directory.io per second. Insane (by todays standards).

The log files definitely belong to you, I'd say somewhere between 70 to 80% of the pool capacity is your clients.

For me it's interesting to see how the server scales. No problem there. WIthout changes, I believe the pool could handle 50 GKeys/s as is.


Rico

[rico666]

The current .blf file contains now also P2SH addresses.

As of now, even if we find a privkey to a hash160 belonging to a P2SH address, we will not be able to do anything with it, but as there seem to be very efficient and GPU-friendly implementations how to get access - in time we will have them.

This means the blf file now contains over 14 million addresses we check against, the false positive rate is currently around 10^-23.x - that's nearly 10000 times higher than with our previous BLF files, so I consider this experimental. If it turns out there is too much noise, I will deactivate P2SH search again.

On the positive side, this means our mean search space until a collision is found is only 136.2bits (checking currently against 14582689 addresses). If it turns out all is working, I will adjust the stats and theory section accordingly.


Rico

[Real-Duke]

Ask for work... got blocks [1080203856-1080210383]

 
Thats me:

Code:

Ask for work... got blocks [1147238848-1147247615] (9193 Mkeys)

So cute compared to yours 

[Jude Austin]

Rico,

You mentioned that someone wanted a way to get notifications of found addresses...

Why not use Pushbullet?

I use it for some other stuff I do and I like it a lot.

Check it out: https://www.pushbullet.com/

Thanks,
Jude

[rico666]

It's official: 7 million pages on directory.io per second

My understanding is, most of this is done by one man and with CPUs.


Pool operation is seamless so far, I've seen a 13seconds network hiccup yesterday (which all clients handled well within 2 retries), and today I experienced a 500 error when calling the stats page. This too seems to have been only transient, although there may be some race condition at the bottom of this. => Pool operation purring like a cat

At the moment I'm completely dissecting the GPU client, as the segmentation faults I've been observing (read: have been driving me mad) for the past couple of days are 100% not my programming fault, but some internal error of the Nvidia OpenCL implementation. I'm trying to find a workaround and/or thorough internal analysis report to submit to Nvidia.


Rico

[GoldTiger69]

It's official: 7 million pages on directory.io per second

My understanding is, most of this is done by one man and with CPUs.


Pool operation is seamless so far, I've seen a 13seconds network hiccup yesterday (which all clients handled well within 2 retries), and today I experienced a 500 error when calling the stats page. This too seems to have been only transient, although there may be some race condition at the bottom of this. => Pool operation purring like a cat

At the moment I'm completely dissecting the GPU client, as the segmentation faults I've been observing (read: have been driving me mad) for the past couple of days are 100% not my programming fault, but some internal error of the Nvidia OpenCL implementation. I'm trying to find a workaround and/or thorough internal analysis report to submit to Nvidia.


Rico

And what about AMD? are you gonna do implementations for those too?