TooDumbForBitcoin
Legendary
Offline
Activity: 1638
Merit: 1001
|
|
March 15, 2017, 11:08:02 AM |
|
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
Member
Offline
Activity: 62
Merit: 10
|
|
March 15, 2017, 11:24:46 AM |
|
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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 15, 2017, 11:44:25 AM |
|
Rico you should update the trophies page Done: https://lbc.cryptoguru.org/trophiesAs 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
Member
Offline
Activity: 62
Merit: 10
|
|
March 15, 2017, 06:05:01 PM |
|
Rico you should update the trophies page Done: https://lbc.cryptoguru.org/trophiesAs 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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 15, 2017, 08:54:48 PM |
|
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
Legendary
Offline
Activity: 1140
Merit: 1000
The Real Jude Austin
|
|
March 15, 2017, 10:22:22 PM |
|
Rico you should update the trophies page Done: https://lbc.cryptoguru.org/trophiesAs 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?
|
Buy or sell $100 of Crypto and get $10!
|
|
|
unknownhostname
Member
Offline
Activity: 62
Merit: 10
|
|
March 15, 2017, 10:43:21 PM |
|
Wow...
Botnet?
Nop ... just free cloud
|
|
|
|
Jude Austin
Legendary
Offline
Activity: 1140
Merit: 1000
The Real Jude Austin
|
|
March 16, 2017, 05:15:49 AM |
|
Wow...
Botnet?
Nop ... just free cloud Free cloud, as in I can join in on this fun? I can haz teh clowd?
|
Buy or sell $100 of Crypto and get $10!
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 16, 2017, 07:07:37 AM Last edit: March 16, 2017, 08:35:15 AM by 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
Member
Offline
Activity: 62
Merit: 10
|
|
March 16, 2017, 10:46:40 AM |
|
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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 16, 2017, 11:00:23 AM |
|
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
Member
Offline
Activity: 62
Merit: 10
|
|
March 16, 2017, 12:31:10 PM |
|
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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 16, 2017, 04:56:35 PM Last edit: March 16, 2017, 05:15:25 PM by rico666 |
|
Ask for work... got blocks [1080203856-1080210383]
We have officially searched about 11 tn keys in #51 search space. [1087617328, 1087624239] <<< Unknownhostname out of 1125 tn keys so about 1% done edit: 384 MKeys/s = 3 million pages on directory.io per secondRico
|
|
|
|
unknownhostname
Member
Offline
Activity: 62
Merit: 10
|
|
March 16, 2017, 06:16:43 PM |
|
edit: 384 MKeys/s = 3 million pages on directory.io per secondRico The real speed right now is more than 500Mkeys/s I guess. Ask for work... got blocks [1091773040-1091779951]
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 16, 2017, 07:05:17 PM |
|
edit: 384 MKeys/s = 3 million pages on directory.io per secondRico 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 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 16, 2017, 10:26:42 PM |
|
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
Legendary
Offline
Activity: 3528
Merit: 2314
Top Crypto Casino
|
|
March 17, 2017, 04:56:19 PM |
|
Ask for work... got blocks [1080203856-1080210383]
Thats me: Ask for work... got blocks [1147238848-1147247615] (9193 Mkeys) So cute compared to yours
|
|
|
|
Jude Austin
Legendary
Offline
Activity: 1140
Merit: 1000
The Real Jude Austin
|
|
March 17, 2017, 09:36:22 PM |
|
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
|
Buy or sell $100 of Crypto and get $10!
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
March 18, 2017, 11:16:56 AM |
|
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
|
|
March 18, 2017, 06:50:45 PM |
|
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?
|
|
|
|
|