Well, Tokes uses Incent's ICO management platfrom while the others use Lisk's?
I'm not really sure though!
Topic: Large Bitcoin Collider (Collision Finders Pool) - page 45. (Read 193484 times)
On the other hand, it appears that the private key was communicated to you so in theory you could swipe any funds the pool finds. This is concerning. Am I missing something?
As I wrote, my client found the colliding hash160, so naturally my client communicated the private key to me.
It's actually a little bit unfortunate, because if it had been found by someone else, we might have another indication (still no proof), that I was not involved with that address in any way.
In other cases (e.g. the puzzle transaction), it's up to the client operators if they give feedback to me about the private keys found. AFAIK they did so - albeit sometimes with 1 week delay - so far. I mean it is something to brag about - isn't it?
Rico
I'd like to point the fellow readers' attention to my signature. If you care to remember, you saw there around 500000 keys/s per CPU core, today maybe shortly some 617 000 keys/s per CPU core and now we are at ~ 712000 keys/s per CPU core.
It's all on the same machine (my notebook E3-1505M CPU).
So what's the reason for the speed bump?
It's simple. Pieter Wuille can't program. Or RyanC or both.
Exaggerating - of course. There's nothing wrong with their programming skills - mine are just better.
The secp256k1 library wants to convert a field element to a 32-byte big endian value like this:
This seems a little bit awkward to me. All these computations and n(i|y)bble bashing must certainly eat up CPU cycles.
My take on it (5x52 field):
Have fun.
Rico
It's all on the same machine (my notebook E3-1505M CPU).
So what's the reason for the speed bump?
It's simple. Pieter Wuille can't program. Or RyanC or both.
Exaggerating - of course. There's nothing wrong with their programming skills - mine are just better.
The secp256k1 library wants to convert a field element to a 32-byte big endian value like this:
Code:
static void secp256k1_fe_get_b32(unsigned char *r, const secp256k1_fe_t *a) {
int i;
#ifdef VERIFY
VERIFY_CHECK(a->normalized);
secp256k1_fe_verify(a);
#endif
for (i=0; i<32; i++) {
int j;
int c = 0;
for (j=0; j<2; j++) {
int limb = (8*i+4*j)/52;
int shift = (8*i+4*j)%52;
c |= ((a->n[limb] >> shift) & 0xF) << (4 * j);
}
r[31-i] = c;
}
}
This seems a little bit awkward to me. All these computations and n(i|y)bble bashing must certainly eat up CPU cycles.
My take on it (5x52 field):
Code:
static void hrdec_fe_get_b32(uchar *r, const secp256k1_fe *a) {
r[31] = a->n[0] & 0xFF; // i = 0
r[30] = (a->n[0] >> 8) & 0xFF; // i = 1
r[29] = (a->n[0] >> 16) & 0xFF; // i = 2
r[28] = (a->n[0] >> 24) & 0xFF; // i = 3
r[27] = (a->n[0] >> 32) & 0xFF; // i = 4
r[26] = (a->n[0] >> 40) & 0xFF; // i = 5
r[25] = ((a->n[0] >> 48) & 0xF) // i = 6
| ((a->n[1] & 0xF) << 4);
r[24] = (a->n[1] >> 4) & 0xFF; // i = 7
r[23] = (a->n[1] >> 12) & 0xFF; // i = 8
r[22] = (a->n[1] >> 20) & 0xFF; // i = 9
r[21] = (a->n[1] >> 28) & 0xFF; // i = 10
r[20] = (a->n[1] >> 36) & 0xFF; // i = 11
r[19] = (a->n[1] >> 44) & 0xFF; // i = 12
r[18] = a->n[2] & 0xFF; // i = 13
r[17] = (a->n[2] >> 8) & 0xFF; // i = 14
r[16] = (a->n[2] >> 16) & 0xFF; // i = 15
r[15] = (a->n[2] >> 24) & 0xFF; // i = 16
r[14] = (a->n[2] >> 32) & 0xFF; // i = 17
r[13] = (a->n[2] >> 40) & 0xFF; // i = 18
r[12] = ((a->n[2] >> 48) & 0xF) // i = 19
| ((a->n[3] & 0xF) << 4);
r[11] = (a->n[3] >> 4) & 0xFF; // i = 20
r[10] = (a->n[3] >> 12) & 0xFF; // i = 21
r[9] = (a->n[3] >> 20) & 0xFF; // i = 22
r[8] = (a->n[3] >> 28) & 0xFF; // i = 23
r[7] = (a->n[3] >> 36) & 0xFF; // i = 24
r[6] = (a->n[3] >> 44) & 0xFF; // i = 25
r[5] = a->n[4] & 0xFF; // i = 26
r[4] = (a->n[4] >> 8) & 0xFF; // i = 27
r[3] = (a->n[4] >> 16) & 0xFF; // i = 28
r[2] = (a->n[4] >> 24) & 0xFF; // i = 29
r[1] = (a->n[4] >> 32) & 0xFF; // i = 30
r[0] = (a->n[4] >> 40) & 0xFF; // i = 31
}
Have fun.
Rico
Let me get this right? This is a project to gain private keys from wallets that have funds in them? correct?
No, this is a project to compute compressed and uncomressed hash160 for all private keys in the 1st 2^160 bits search space.
There is no "finding" private keys, as the private keys are simply 256bit numbers being incremented.
If by "finding" you mean finding a "hit" where the generated hash160 corresponds to some hash160 with unspent balance, then yes.
Rico
A discussion can't happen if there are no arguments presented. Your claim is backed only by underlined bold fonts:
I swear I have nothing to do with this address - except my client found its private key tonight!
Arrogance is a primitive defense caused by the lack of arguments. Your arrogance is quite amusing, my dear friend.
No my little retard. The bold text was just the initial statement.
Arguments followed like date of deposit on the address in question, start of the LBC project (2 years later) etc.
The only "amusing" thing here is, that you managed to get a legendary (...) account status by vomiting countless worthless 2-line contributions all over the place. IMHO your account would give a perfect test case for the account price estimator like "pathological account detected! value: 0 BTC"
Rico
Quote
Right now, the pool has had only one true find after searching 35 trillion keys.
How do we know? Is it on the stats page?
It's on the trophies page:
https://lbc.cryptoguru.org/trophies
Rico
This is nice since once the pool finds more we can extrapolate and glean some valuable information about the feasibility of this project.
On the other hand, it appears that the private key was communicated to you so in theory you could swipe any funds the pool finds. This is concerning. Am I missing something?
Let me get this right? This is a project to gain private keys from wallets that have funds in them? correct?
The correct question is:
How do we know it is not one of your own keys?
How do we know it is not one of your own keys?
Yo my fellow retard becoin! We had that discussion already. Remember?
See https://bitcointalksearch.org/topic/m.16523548
ff.
A discussion can't happen if there are no arguments presented. Your claim is backed only by underlined bold fonts:
I swear I have nothing to do with this address - except my client found its private key tonight!
Arrogance is a primitive defense caused by the lack of arguments. Your arrogance is quite amusing, my dear friend.
The correct question is:
How do we know it is not one of your own keys?
How do we know it is not one of your own keys?
Yo my fellow retard becoin! We had that discussion already. Remember?
See https://bitcointalksearch.org/topic/m.16523548
ff.
Also, as for the theory behind the pool: https://lbc.cryptoguru.org/man/theory
educate yourself 1st if you want to participate in the discussion.
If you have real issues with the pool, articulate yourself clearly. Present facts, arguments,
examples, counterexamples or whatever.
If you do not want to lead a funded discussion, open your own thread and vomit there
and do not pollute this thread as it seems you cannot help yourself from time to time.
Merry Christmas.
Rico
Quote
Right now, the pool has had only one true find after searching 35 trillion keys.
How do we know? Is it on the stats page?
The correct question is:
How do we know it is not one of your own keys?
Quote
Right now, the pool has had only one true find after searching 35 trillion keys.
How do we know? Is it on the stats page?
It's on the trophies page:
https://lbc.cryptoguru.org/trophies
Rico
Quote
Right now, the pool has had only one true find after searching 35 trillion keys.
How do we know? Is it on the stats page?
Ok, now it works!!! Thanks!!
Code:
antonio@ubuntu:~/collider$ rm LBC
antonio@ubuntu:~/collider$ wget ftp://ftp.cryptoguru.org/LBC/client/LBC
--2016-12-20 14:05:35-- ftp://ftp.cryptoguru.org/LBC/client/LBC
=> "LBC"
Risoluzione di ftp.cryptoguru.org (ftp.cryptoguru.org)... 92.43.104.60
Connessione a ftp.cryptoguru.org (ftp.cryptoguru.org)|92.43.104.60|:21... connesso.
Accesso come utente anonymous ... Accesso eseguito.
==> SYST ... fatto. ==> PWD ... fatto.
==> TYPE I ... fatto. ==> CWD (1) /LBC/client ... fatto.
==> SIZE LBC ... 34675
==> PASV ... fatto. ==> RETR LBC ... fatto.
Lunghezza: 34675 (34K) (non autorevole)
LBC 100%[====================================>] 33,86K --.-KB/s in 0,05s
2016-12-20 14:05:35 (671 KB/s) - "LBC" salvato [34675]
antonio@ubuntu:~/collider$ ls -al *
-rw-r--r-- 1 antonio root 114 dic 19 22:41 bench.pst
-rw-r--r-- 1 antonio root 472 dic 19 22:43 FOUND.txt
-rw-r--r-- 1 antonio antonio 536870912 dic 19 17:36 funds_h160.blf
-rwxr-xr-x 1 antonio antonio 1074624 dic 19 17:10 gen-hrdcore-sse41-linux64
-rw-r--r-- 1 antonio antonio 34675 dic 20 14:05 LBC
-rw-r--r-- 1 antonio root 50166 dic 18 18:56 LBCdiag.txt
antonio@ubuntu:~/collider$ sudo ./LBC -c 1 -t 1:0
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... got blocks [200617417-200618024] (637 Mkeys)
oo
Code:
-rwxr-xr-x 1 antonio antonio 34671 dic 18 16:06 LBC
antonio@ubuntu:~/collider$ sudo ./LBC -c 1 -t 1:0
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: error 0x567.
Another error...
Then we are back at the "you have tampered with the LBC source code" hypothesis.
Code:
$ wget ftp://ftp.cryptoguru.org/LBC/client/LBC
$ ll LBC
-rwxr-xr-x 1 rico rico 34675 Dec 20 13:30 LBC
LBC should be 34675 bytes long - not 34671
Rico
Code:
antonio@ubuntu:~/collider$ sudo ./LBC -V
[sudo] password di antonio:
0.899
antonio@ubuntu:~/collider$ sudo chown antonio *
antonio@ubuntu:~/collider$ ls -al *
-rw-r--r-- 1 antonio root 114 dic 19 22:41 bench.pst
-rw-r--r-- 1 antonio root 472 dic 19 22:43 FOUND.txt
-rw-r--r-- 1 antonio antonio 536870912 dic 19 17:36 funds_h160.blf
-rwxr-xr-x 1 antonio antonio 1074624 dic 19 17:10 gen-hrdcore-sse41-linux64
-rwxr-xr-x 1 antonio antonio 34671 dic 18 16:06 LBC
-rw-r--r-- 1 antonio root 50166 dic 18 18:56 LBCdiag.txt
antonio@ubuntu:~/collider$ sudo ./LBC -c 1 -t 1:0
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: error 0x567.
Another error...
Hi,
Ok.
what does ./LBC -v say? You should have version 0.899
If you do have version 0.899, then the messages simply say you have tampered with the LBC source code.
If you haven't - which is the better alternative - the file "bench.pst" is simply not readable to LBC.
In that case, it should be sufficient to do a "sudo chown antonio *" on the files.
Rico
My test is ok:
Ok.
Quote
Ask for work... Server doesn't like us. Answer: malformed request.
what does ./LBC -v say? You should have version 0.899
If you do have version 0.899, then the messages simply say you have tampered with the LBC source code.
If you haven't - which is the better alternative - the file "bench.pst" is simply not readable to LBC.
In that case, it should be sufficient to do a "sudo chown antonio *" on the files.
Rico
My test is ok:
but then:
What is the problem?
Code:
antonio@ubuntu:~/collider$ sudo ./LBC -x
Will use 0 CPUs.
Best generator chosen: gen-hrdcore-sse41-linux64
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 204516 keys/s per CPU core.
PAGE-TO: 0 PAGE-FROM: 0
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
o2d17543d32448acc7a1c43c5f72cd5be459ab302:u:(hex)priv:000000000000000000000000000000000000000000000000000000000000005f
02e62151191a931d51cdc513a86d4bf5694f4e51:c:(hex)priv:0000000000000000000000000000000000000000000000000000000000000066
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
3d6871076780446bd46fc564b0c443e1fd415beb:c:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
Ending test run.
antonio@ubuntu:~/collider$ ls
bench.pst FOUND.txt funds_h160.blf gen-hrdcore-sse41-linux64 LBC
but then:
Code:
sudo ./LBC
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: perm withdrawn.
antonio@ubuntu:~/collider$ sudo ./LBC -c 1 -t 1
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: perm withdrawn.
antonio@ubuntu:~/collider$ sudo ./LBC -l 0 -c 1 -t 1:0
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 0 PAGE-FROM: 0
Ask for work... Server doesn't like us. Answer: malformed request.
antonio@ubuntu:~/collider$ sudo ./LBC -p 1000-1001
Loop off! Work on blocks [1000-1001] (2 Mkeys)
Will use 0 CPUs.
Best generator chosen: gen-hrdcore-sse41-linux64
PAGE-TO: 1001 PAGE-FROM: 1000
Estimated duration: infd NaNh NaNm NaNs
Too many requested pages [1000,1001]. Limiting work per iteration to 1 day.
New range: [1000, 1000].
oServer doesn't like us. Answer: perm withdrawn.
antonio@ubuntu:~/collider$ sudo ./LBC -q
Server answer to 'query' is:
{
"nil" : "malformed request"
}
'done' means we have delivered 0.000 valid Gkeys.
What is the problem?
Yes, every project based on free electricity is nonsense.
I hate to see so much talent wasted on nonsensical projects.
I hate to see so much talent wasted on nonsensical projects.
You are in no position to make any judgement about talent.
Rico
Is this project losing steam?
Come on colliders!
Come on colliders!
I guess for many clients, it seems pointless to always look at
Code:
...
Ask for work... got blocks [177666153-177668392] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177674889-177677128] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177684009-177686248] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177690281-177692520] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177699049-177701288] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177707497-177709736] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177714681-177716920] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177722425-177724664] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177729081-177731320] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177737817-177740056] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177746777-177749016] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Ask for work... got blocks [177753401-177755640] (2348 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
...
yadda yadda - you get the idea
If I didn't know, that between each two 'o' all of a sudden a "FOUND: ..." message may appear and the probability of the hash160 found containing 0.0001 BTC being as high as finding e.g. "bcadb700c24da04b17feb9aa9bd71e368a4b623c", I would miss the motivation too. Maybe it's a good thing, because everyone who participated because he hoped "to make a quick buck" is gone now.
Right now, the pool has had only one true find after searching 35 trillion keys. We have now searched almost 187 trillion keys without another find, so yeah it may be getting boring for some. The attention span of the general population nowadays seems way too short without augmenting medication.
I had lots of other things to do in the past time, but when time allowed it, I looked into the OpenCL generator. I also have a 6% faster CPU generator running here on my notebook from time to time doing janitoring work, but 6% was not worth it to release it yet.
I incspected hashcat for their SHA256 and RIPEMD160 OpenCL code and contrary to vanitygen which has around 15 MKeys/s on my notebook GPU, the hashcat code suggests way more should be possible (RIPEMD160 does 400 Mhash/s, SHA256 does 200MHash/s). I believe with the EC arithmetics and the bloom filter lookup both on GPU, I should be able to squeeze almost 100 MKeys/s out of my GPU.
That is again almost 13 times speedup to my current Pleiades prototype (a hacked vanitygen).
While I do not know exactly when I will be able to spend how much time hacking that, one thing I am pretty sure about: No matter what the stats say,
the pool will hit the private key to 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS in 2017.
Rico
Jump to: