Topic: Large Bitcoin Collider Thread 2.0 - page 9. (Read 57468 times)
Thanks for the answer, rico666! English is not my native language.
It seems to me that LBC now has rather weak control of clients (correctness of their checks and return of results).
So the effect is: in list of Trophies we see far less records than it should be.
Also the main sense and benefit of pool is sharing award between all members (proportionally to contribution).
But now the single member takes everything (and can even not report the find!).
Actually, I do not see any advantages of being member of LBC versus solo mode.
Yeah, I've read the FAQ, but I totally disagree with the answer.
The range of LBC is known (and I think it is not best).
Solo "miner" can easily use another range without being a member of LBC.
The point of this message is not "hey, everyone, run from LBC", but to make LBC better and possibly more popular.
By the way, don't you think that starting from very beginning is a bad idea?
I guess most of us are hoping to discover abandoned wallets from early 2010-s.
At that times harsh cryptofreaks didn't have fancy bitcoin-core software and generated private keys themselves.
So, they at least have seen the result of RNG.
And the secret key with 40 leading zeros looks very stupid.
Yeah, I understand that any value from RNG has the same probability to occur, but still...
Why not to move to middle of 256-bit range (or 2^160 - I'm not sure what exactly we are bruteforcing)?
I guess most of us are hoping to discover abandoned wallets from early 2010-s.
At that times harsh cryptofreaks didn't have fancy bitcoin-core software and generated private keys themselves.
So, they at least have seen the result of RNG.
And the secret key with 40 leading zeros looks very stupid.
Yeah, I understand that any value from RNG has the same probability to occur, but still...
Why not to move to middle of 256-bit range (or 2^160 - I'm not sure what exactly we are bruteforcing)?
A number of people have raised this matter: how to read properly the FOUND.txt file?
I decided to share a little python script.
First we generate a FOUND.txt file to make a test:
Then you can use this python script, called "lbc_output.py": https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0
Copy the line of FOUND.TXT you are interested of and you get the result:
What does the script?
First it reads and parses the line.
Then it computes the private key (it does the addition, in our example: 0000000000000000000000000000000000000000000000000000000000000001 + 0x5e) and using the ecc arithmetic it generates the public key. Then it generates the address (compressed or uncompressed) and checks if it matches with the address in FOUND.txt (in this case 2d17543d32448acc7a1c43c5f72cd5be459ab302).
Finally it provides the private key in WIF format and the address b58 encoded.
I decided to share a little python script.
First we generate a FOUND.txt file to make a test:
Code:
$ ./LBC -x
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly ............ keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
$ ls
FOUND.txt
....
$ more FOUND.txt
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
Then you can use this python script, called "lbc_output.py": https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0
Copy the line of FOUND.TXT you are interested of and you get the result:
Code:
$ ./lbc_output.py 2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
Private key : 000000000000000000000000000000000000000000000000000000000000005f
Public key :
x : 15d9441254945064cf1a1c33bbd3b49f8966c5092171e699ef258dfab81c045c
y : d56eb30b69463e7234f5137b73b84177434800bacebfc685fc37bbe9efe4070d
PrKey WIF u.: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreMQiR4w7
Address u. : 2d17543d32448acc7a1c43c5f72cd5be459ab302
Address u. : 157RMZhbBLC1wucv3jxQqqHjbKezL1yy7g
What does the script?
First it reads and parses the line.
Then it computes the private key (it does the addition, in our example: 0000000000000000000000000000000000000000000000000000000000000001 + 0x5e) and using the ecc arithmetic it generates the public key. Then it generates the address (compressed or uncompressed) and checks if it matches with the address in FOUND.txt (in this case 2d17543d32448acc7a1c43c5f72cd5be459ab302).
Finally it provides the private key in WIF format and the address b58 encoded.
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?
Jump to: