Topic: Large Bitcoin Collider Thread 2.0 - page 9. (Read 57116 times)
Joining up!
1. What perl program does when the collision is found? Only writes to file FOUND.txt? If I someone overlook/delete this file, nobody will even know that we found the key and the worst thing - this range should be marked as empty? 
See https://lbc.cryptoguru.org/man/user#hooks
Quote
2. Is there any validation of results? Or just checking checksums of the program itself? Why not to compute each block's checksum (even simplest in couple of bytes) and send to server?
Then make 10% of work-units overlap. If checksums do not match, sending to third client and marking ALL work from client with wrong checksum as undone and ban him if there were several badly processed blocks.
For now it seems like we are sifting with too large sieve?
Then make 10% of work-units overlap. If checksums do not match, sending to third client and marking ALL work from client with wrong checksum as undone and ban him if there were several badly processed blocks.
For now it seems like we are sifting with too large sieve?
Some overlap happens already, although it's less than 2%
Work is also being re-issued.
Not sure what you mean by the "too large sieve". Rest assured, validation is working fine.
I do understand that the author needed to implement a way to make sure the data sent to the server is always valid. If not, the whole project is failing...
Hello, guys! Just joined my modest 10Mkps to your great project. But I still have a couple of questions...
1. What perl program does when the collision is found? Only writes to file FOUND.txt? If I someone overlook/delete this file, nobody will even know that we found the key and the worst thing - this range should be marked as empty?
2. Is there any validation of results? Or just checking checksums of the program itself? Why not to compute each block's checksum (even simplest in couple of bytes) and send to server?
Then make 10% of work-units overlap. If checksums do not match, sending to third client and marking ALL work from client with wrong checksum as undone and ban him if there were several badly processed blocks.
For now it seems like we are sifting with too large sieve?
Ah, thanks for clarification. It's obvious when you see the answer 
Excuse me for not reading everything about LBC, but who found the keys corresponding to 0.161 - 0.256 BTC outputs range in the Puzzle transaction? There are somehow derived from 0.001 to 0.054 private keys?
https://bitcointalksearch.org/topic/m.18765941
Excuse me for not reading everything about LBC, but who found the keys corresponding to 0.161 - 0.256 BTC outputs range in the Puzzle transaction? There are somehow derived from 0.001 to 0.054 private keys?
Those were moved by the creator (of the puzzle) because they were redundant.
Excuse me for not reading everything about LBC, but who found the keys corresponding to 0.161 - 0.256 BTC outputs range in the Puzzle transaction? There are somehow derived from 0.001 to 0.054 private keys?
Ok done. Here is the transaction ID
https://blockchain.info/tx/1ec00c68cf375cec164271086cae7e8897302da299c7a6de5038f586c4b95823
Lets find the 55th number now!
https://blockchain.info/tx/1ec00c68cf375cec164271086cae7e8897302da299c7a6de5038f586c4b95823
Lets find the 55th number now!
Ok, I finally sold those Bitcore AND Bitcoin Gold coins from the 54th key.
I think I sold the BTG for around ~0.038 and the Bitcore was like $8 or so. So I will send over half as promised.
However little did I know that Hitbtc sends BTC from Segwit addresses and my Electrum isn't upgraded yet. So I need to upgrade first before I can send over the BTC to you. So give me a few days to do so.
I think I sold the BTG for around ~0.038 and the Bitcore was like $8 or so. So I will send over half as promised.
However little did I know that Hitbtc sends BTC from Segwit addresses and my Electrum isn't upgraded yet. So I need to upgrade first before I can send over the BTC to you. So give me a few days to do so.
Please update the LBC performance spreadsheet with your keys/sec instead of this thread:
https://docs.google.com/spreadsheets/d/1n6rh-0fMVYPEd69cD-3YPcFlgJaxBNh_bZr94kQSvIs/edit?usp=sharing
https://docs.google.com/spreadsheets/d/1n6rh-0fMVYPEd69cD-3YPcFlgJaxBNh_bZr94kQSvIs/edit?usp=sharing
I have installed a fresh copy of CentOS instead of the ArchLinux LBC Appliance, and can confirm it is now working as expected!... Also, Min 2^24 per CPU according to rico666
We have tried it with 1 page and 1000 pages still no hit!...
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Will use 2 CPUs.
Estimated duration: 35.013005625s
oo (2.02 Mkeys/s)
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Will use 2 CPUs.
Estimated duration: 35.013005625s
oo (2.02 Mkeys/s)
Try with a wider interval:
Example:
Code:
$ ./LBC -c 1 -p 9512381750-9512381800
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 7.5619516875s
ooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001 + 0xf42
(1.01 Mkeys/s)
$ ./LBC -c 2 -p 9512381750-9512381800
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 3.855112625s
oo (2.86 Mkeys/s)
$ ./LBC -c 2 -p 9512381700-9512381850
Loop off! Work on blocks [9512381700-9512381850] (158 Mkeys)
Estimated duration: 11.26879075s
ooooooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001 + 0xf42
o (2.15 Mkeys/s)
As you can see, in the first case the program computes 3 'o' (3*2^24 keys, about 50.3 Mkeys) instead of 53 Mkeys.
In the second case it computes only 2 'o' (2*2^24 keys, about 33.4 Mkeys) instead of 53 Mkeys.
In the third case it computes 8 'o' (8*2^24 keys, about 134 Mkeys) instead of 158 Mkeys.
Maybe the rounding error is < number of cpus * 2^24 keys (I'm not sure).
EDIT: if you try directly with the generator:
Code:
$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f40 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f40 + 0x3
$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f41 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f41 + 0x2
$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f42 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f42 + 0x1
$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f43 + 0
there are no problems.
./LBC -x does display the 4 planted priv keys
We have tried it with 1 page and 1000 pages still no hit!...
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Will use 2 CPUs.
Estimated duration: 35.013005625s
oo (2.02 Mkeys/s)
[root@osboxes collider]#
Another person on "discord" also tried and wasn't about to find anything.
I am currently using the LBC appliance with VMware 14... Also wasn't able to run LBC as user: osboxes
[osboxes@osboxes collider]$ ./LBC -x
XS.c: loadable library and perl binaries are mismatched (got handshake key 0xdb80080, needed 0xde00080)
However, executing as root user will work...
We have tried it with 1 page and 1000 pages still no hit!...
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Will use 2 CPUs.
Estimated duration: 35.013005625s
oo (2.02 Mkeys/s)
[root@osboxes collider]#
Another person on "discord" also tried and wasn't about to find anything.
I am currently using the LBC appliance with VMware 14... Also wasn't able to run LBC as user: osboxes
[osboxes@osboxes collider]$ ./LBC -x
XS.c: loadable library and perl binaries are mismatched (got handshake key 0xdb80080, needed 0xde00080)
However, executing as root user will work...
Hi, Is there anyway i can test too see if LBC client is working and reporting properly...
./LBC -x
Quote
I have tried running the following to find the last puzzle address #54.. but it doesn't report a find
./LBC -c 3 -p '#x236fb6d5ad1040-#x236fb6d5ad1f49'
and i have tried
./LBC -c 3 -p '1-2'
Still no FOUND.txt file produced...
./LBC -c 3 -p '#x236fb6d5ad1040-#x236fb6d5ad1f49'
and i have tried
./LBC -c 3 -p '1-2'
Still no FOUND.txt file produced...
The range you're giving is way too small. I'm not sure LBC works correctly if you give it a range of some few dozens of individual keys.
This ant shit is probably getting borked by rounding errors.
LBC is made to check billions of keys, so don't try to navigate the USS Nimitz in your bath tub.
Code:
LBC -c 1 -p 9512381750-9512381800
is only 53 Mkeys and should work for #54. At least it does on my computer:
Code:
$ LBC -c 1 -p 9512381750-9512381800
GPU authorized: yes
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 7.8355125s
ooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001+0xf42
(6.19 Mkeys/s)
Hi, Is there anyway i can test too see if LBC client is working and reporting properly...
I have tried running the following to find the last puzzle address #54.. but it doesn't report a find
./LBC -c 3 -p '#x236fb6d5ad1040-#x236fb6d5ad1f49'
and i have tried
./LBC -c 3 -p '1-2'
Still no FOUND.txt file produced...
Thanks
I have tried running the following to find the last puzzle address #54.. but it doesn't report a find
./LBC -c 3 -p '#x236fb6d5ad1040-#x236fb6d5ad1f49'
and i have tried
./LBC -c 3 -p '1-2'
Still no FOUND.txt file produced...
Thanks
I said we lost 3/4 of the pool speed and that message got deleted.
What did I do wrong by writing that?
What did I do wrong by writing that?
I reserve the right to remove Cpt. Obvious, low quality, low information content messages.
Obviously I am still very benevolent, so do not push it.
I said we lost 3/4 of the pool speed and that message got deleted.
What did I do wrong by writing that?
What did I do wrong by writing that?
Never mind. Figured it out :-)
But I just noticed our pool performance dropped from over 2000Mkeys/sec to only 600MKeys/sec...
But I just noticed our pool performance dropped from over 2000Mkeys/sec to only 600MKeys/sec...
From 2200 to 550 actually. One man who turns his machines on/off. ;-)
Never mind. Figured it out :-)
But I just noticed our pool performance dropped from over 2000Mkeys/sec to only 600MKeys/sec...
But I just noticed our pool performance dropped from over 2000Mkeys/sec to only 600MKeys/sec...
I have just copied over bench.pst, FOUND.txt, fund_h160.blf, kardashev-* and LBC to a different server and ran "./LBC -q --secret mysecret" but I get this back:
Server answer to 'query' is:
{
"nil" : "wrong secret"
}
What files am I missing?
Server answer to 'query' is:
{
"nil" : "wrong secret"
}
What files am I missing?
Jump to: