Large Bitcoin Collider (Collision Finders Pool)

[sana98212]

When the International Quantum Computing Society inaugurates it's Cryptocurrency Hacker of the Year award in 2025, will it be called the Rico in honor of the pioneer in collision computing?

I don't know. Quantum computing is only 4th on my TODO list.

1. Full-GPU client
2. FPGA implementation
3. ASIC
4. Quantum Computing


Rico

So what? What does this matter? by the time you use quantum computers or asics and start finding tens and tens of collisions, bitcoin will worth 1 dll because people will move to other one more secure.

Have you ever thought about this?

[rico666]

aaand I got blacklisted while using the beta build only on CPU.

How could you use the GPU client if you have no GPU auth?

I had a look at the logs: Shortly after you said here "top30 here I come", your client started to churn invalid blocks to the server, so the server blacklisted you and the contributed 278,8 Gkeys got invalidated.

As it should be - IMHO.


Rico

[rico666]

So what? What does this matter? by the time you use quantum computers or asics and start finding tens and tens of collisions, bitcoin will worth 1 dll because people will move to other one more secure.

Have you ever thought about this?

No I haven't. I have sworn to myself to pull this project off without any thinking at all.


Rico

[shifty252]

aaand I got blacklisted while using the beta build only on CPU.

How could you use the GPU client if you have no GPU auth?

I had a look at the logs: Shortly after you said here "top30 here I come", your client started to churn invalid blocks to the server, so the server blacklisted you and the contributed 278,8 Gkeys got invalidated.

As it should be - IMHO.


Rico

i ran it like this: ./LBC --id shifty252 --secret xxxxxxx -c 4

then it started and said no gpu found, will use 4 cpus but it also threw about 4 error lines about an unknown command "-L"  but it went on asking for work so I let it be.

[SlarkBoy]

after following your instruction


1st run

Code:

Illegal instruction (core dumped)

And we are sure the CPU is AVX2 capable?


Rico

My CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

[sana98212]

So what? What does this matter? by the time you use quantum computers or asics and start finding tens and tens of collisions, bitcoin will worth 1 dll because people will move to other one more secure.

Have you ever thought about this?

No I haven't. I have sworn to myself to pull this project off without any thinking at all.


Rico

Well let's see how the LBC evolves, thankyou.

[arulbero]

I was thinking, if sha256/ripemd160 is too fast compared to CPU pk generation, you could search for P2SH "addresses" too.

For example, with only 3 pubkeys, you could generate about 20 addresses (probably more):

6

Code:

{2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}

+6

Code:

{1 [pubkey1] [pubkey2] 2 OP_CHECKMULTISIG}

+3

Code:

{1 [pubkey1] 1 OP_CHECKMULTISIG}

[rico666]

My CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

Ok. It seems the GPU generator is working on Broadwell, Skylake and Kaby Lake.
I'm working on compiles for the older architectures too and will post here when they're available.

Rico

[Haze]

Good morning!

HeavenlyCreatures found #49

Code:

From	XXX
To	bots@cryptoguru.org
Date	Today 08:02
Hi,

I found #49

0d2f533966c6578e1111978ca698f8add7fffdf3:c:priv:000000000000000000000000000000000000000000000000000174176b015001
+ 0xf4c

Looking at the PK, the pool must have found it GMT: Sat, 11 Feb 2017 04:32:26 GMT

edit: trophies update.

cheers!

Rico

Sorry, noob here. This doesn't look like a private key and when put into bitcoin address it says invalid. What am I missing?

[Jude Austin]

My CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

Ok. It seems the GPU generator is working on Broadwell, Skylake and Kaby Lake.
I'm working on compiles for the older architectures too and will post here when they're available.

Rico

Patiently waiting, hehe.

[rico666]

Sorry, noob here. This doesn't look like a private key and when put into bitcoin address it says invalid. What am I missing?

In the trophies section, it is all well prepared. If you put the hash160 in the blockchain.info search, you end up on

https://blockchain.info/address/12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF
which is the same page as
https://blockchain.info/de/address/0d2f533966c6578e1111978ca698f8add7fffdf3

and if you convert the private key to a WIF, its 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEXxDuJBiUbiVA9e

I don't see an "invalid" anywhere.

More info: https://lbc.cryptoguru.org/man/user#found-

Rico

[rico666]

Patiently waiting, hehe.

JFYI: The "hrd-core" binary below is a sse42+gpu version with a AMD GPU (R9-280X - I wonder why it's named Hainan, I thought they are Tahiti XTL)

No idea why it's throwing that "Out of host memory" on me. The host is sitting there with 8GB unused memory...

Code:

[root@localhost HRD-GPU]# time ./hrd-core -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 -d 1
OpenCL device chosen: Advanced Micro Devices, Inc. (Hainan)
256/16/1
256/1/1
Couldn't create a command queue: Out of host memory

As soon as I crack this, you will have your toy.

edit: needless to say, it works on NVIDIA platforms without problems:

ubuntu@ip-172-31-44-82:~/collider$ ./LBC --gpu -x
GPU authorized: yes
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 1308421 keys/s per CPU core.
Generator chosen: gen-hrdcore-sse42+gpu-linux64
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:c:priv:0000000000000000000000000000000000000000000000000000000000001001 + 0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:u:priv:0000000000000000000000000000000000000000000000000000000000001001 + 0x66
9d74ffdb31068ca2a1feb8e34830635c0647d714:c:priv:00000000000000000000000000000000000000000000000000000000000fa001 + 0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:u:priv:00000000000000000000000000000000000000000000000000000000000fa001 + 0xf8d
Ending test run.


1308421 keys/s per core - that's on a g2.xlarge (xeon v2 + K80)




Also in the news: ftp://ftp.cryptoguru.org/LBC/generators/

And we are sure the CPU is AVX2 capable?

My CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

You could try some hacking by using the  170220-3a3e82c4efe4a75e07c9c43a46206135.gen-hrdcore-avx2+gpu-linux64.bz2 generator, unpacking and renaming it to gen-hrdcore-gpu-linux64
and starting LBC with all options according to the instructions (as you did) and additionally --no_update (so it doesn't overwrite  your generator).
It might work, because it has been made on Haswell.

Rico

[SlarkBoy]

it works

Code:

root@Meh:~/LBCGPU# ./LBC --id XXXX --secret XXXX --gpu -t 1 -l 1 --no_update
GPU authorized: yes
Will use 4 CPUs.
Benchmark info not found - benchmarking... done.
Your maximum speed is 2232588 keys/s per CPU core.
Ask for work... got blocks [424129113-424129624] (536 Mkeys)
oooooooooooooooooooooooooooooooo (7.00 Mkeys/s)
root@Meh:~/LBCGPU# ./LBC --id XXXX --secret XXXX --gpu -t 1 -l 1 --no_update --cpus 8
GPU authorized: yes
Ask for work... got blocks [424136153-424137176] (1073 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (7.63 Mkeys/s)

[rico666]

it works

Code:

root@Meh:~/LBCGPU# ./LBC --id XXXX --secret XXXX --gpu -t 1 -l 1 --no_update
Your maximum speed is 2232588 keys/s per CPU core.

Congrats! And ... what? ... better keyrate than me? I have to o.p.t.i.m.i.z.e.  more


I'm getting more and more feedback about GPU clients finally working with some heart-lung machine work.
I'll publish a new client soon which wraps up all the fixes, so GPU experience will be smooth.


Rico

[rico666]

I have feedback, that at least one user got his AMD GPU to run with LBC and the sse42+gpu generator.
Which makes him the 1st, because I was not lucky so far. May he come forth and bath in glory (and answer questions/give support  )

The new generators have a new parameter -L you may see in the process table. In case you're wondering what that is:

-L is loops

earlier versions of the generator started up, searched 16M keys, terminated, next startup, searched 16M keys...
so per 'o' one run.

-L <num> will now tell the generator to run <num> loops, i.e. <num> x 16M
this is especially important for GPU generators as they have a high startup cost, but also the CPU generators profit from this.

So if you e.g. see -L 25, this means, the generator will startup and run from a certain offset a search of 25 x 16M keys, which means only 1 startup cost for 400M keys instead of 25 startups.
There is a drawback to this - unfortunately. If you want to end LBC by pressing "e", it will take longer. Namely at the end of the next ask-for-work-block.

Code:

Ask for work... got blocks [426612921-426615288] (2483 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooe <--- here we pressed "e"
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (7.33 Mkeys/s)
Ask for work... got blocks [426626393-426628760] (2483 Mkeys)
<-- here LBC found out
END requested. (Ending this loop) Waiting for children to finish...
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo  <--- here it ends

So max. time from "e" to end is twice the time given in -t


Also, you may see a -d 1 parameter in the process table with the GPU generators.

-d <num> is simply the GPU device to use. If there are several GPUs on the system, this says which one to use. Default is 1

When does one use that? Again, as a LBC user, most of the time you do not need to take care of this, but in case you have a really big iron (say 32 physical CPUs and 4 GPUs), the LBC parameter is called "gdev" aka "GPU device".


Howto - you open 4 windows/terminals:

terminal1: ./LBC --gpu -c 8 -gdev 1
terminal2: ./LBC --gpu -c 8 -gdev 2
terminal3: ./LBC --gpu -c 8 -gdev 3
terminal4: ./LBC --gpu -c 8 -gdev 4

=> you should have 4 LBCs running, each taming 8 generators (8 CPUs + 1 GPU)
used if e.g. 8 CPUs are right to saturate 1 GPU


Rico

[rico666]

but it also threw about 4 error lines about an unknown command "-L"  but it went on asking for work so I let it be.

And that is something you shouldn't have done. When I asked for GPU beta testers, there were several prerequisites.
Among them there were

• If you have GPU authorization
• If you are bold

You had no GPUauth, but you were extremely bold, which means you can handle the consequences.
At the moment I handle the consequences too, because I put my client on rectifying your 278+ Gkeys of invalid mess.
If you really are interested to help out in the project and not making things worse, PM me.

BTW - this (PM me) applies to everyone who feels he can't make it into top30, cannot fork out 0.1BTC and would like to explore the 3rd option

How does that gpuauth=1 happen?
...

• You get a gpuauth set to 1 by decree (i.e. for special services)

Rico

[rico666]

No I haven't. I have sworn to myself to pull this project off without any thinking at all.

Well let's see how the LBC evolves, thankyou.

Of course my answer was sarcasto-ironic (which I often do to stimulate thinking in my discussion counterpart, but it almost never works).
So full verbatim, my answer translates to this:

There are currently P2PKH and P2SH addresses. We search only P2PKH, but we may extend our search to P2SH.

This "If you find collisions BTC will die/will be worth nothing" is FUD. Bitcoin is an evolving system. And yes, LBC may put evolutionary pressure on the P2PKH part right now.
If you look at https://github.com/bitcoin/bips/blob/master/README.mediawiki, you will see that there are other address formats already proposed.

E.g. the now deferred BIP142 defining a P2WPKH format.

Others may follow (I'd propose a true-512bit address format in a BIP myself, but am lacking the time atm. Also I prefer to interact with core devs as few as possible).

In other words: There are so many levels between LBC finding collisions and BTC dying, one can safely assume these two events are not connected. Also I do not believe in the 2nd one.


Rico

[shifty252]

but it also threw about 4 error lines about an unknown command "-L"  but it went on asking for work so I let it be.

And that is something you shouldn't have done. When I asked for GPU beta testers, there were several prerequisites.
Among them there were

• If you have GPU authorization
• If you are bold

You had no GPUauth, but you were extremely bold, which means you can handle the consequences.
At the moment I handle the consequences too, because I put my client on rectifying your 278+ Gkeys of invalid mess.
If you really are interested to help out in the project and not making things worse, PM me.

BTW - this (PM me) applies to everyone who feels he can't make it into top30, cannot fork out 0.1BTC and would like to explore the 3rd option

How does that gpuauth=1 happen?
...

• You get a gpuauth set to 1 by decree (i.e. for special services)

Rico

You're right, I deserve what came after the mess , BUT:

Ok guys - this is it:

Everyone who has a working OpenCL install, is authorized for GPU, has an AVX2 capable CPU (I will provide sse42 GPU clients later) and feels bold enough, please download the beta from.

This was way misleading and it read like anyone with gpu and opencl installed may try the beta.

This is were my error is.

[rico666]

New client 1.029 - upon restart your LBC should auto-update.

Also, most generators (except generic and sse41) have been updated to accept the -L option.
These too, should auto update.

Everyone who is GPU auth, should now be plug and play via --gpu.

The names of the generators are now in a more canonical form.

gen-hrdcore-skylake-linux64  (CPU)
gen-hrdcore-skylake+gpu-linux64 (CPU+GPU)
gen-hrdcore-avx2-linux64  (CPU)
gen-hrdcore-avx2+gpu-linux64 (CPU+GPU)
...etc. - you get the idea

So basically if you had a gen-hrdcore-avx2-linux64 generator up to now, with --gpu LBC would fetch the gen-hrdcore-avx2+gpu-linux64 counterpart and use that.

Even if you are CPU only, an update makes sense, as the -L will lower the generator startup overhead and should give you some more keys/s

Rico

[Jude Austin]

I have feedback, that at least one user got his AMD GPU to run with LBC and the sse42+gpu generator.
Which makes him the 1st, because I was not lucky so far. May he come forth and bath in glory (and answer questions/give support  )

The new generators have a new parameter -L you may see in the process table. In case you're wondering what that is:

-L is loops

earlier versions of the generator started up, searched 16M keys, terminated, next startup, searched 16M keys...
so per 'o' one run.

-L <num> will now tell the generator to run <num> loops, i.e. <num> x 16M
this is especially important for GPU generators as they have a high startup cost, but also the CPU generators profit from this.

So if you e.g. see -L 25, this means, the generator will startup and run from a certain offset a search of 25 x 16M keys, which means only 1 startup cost for 400M keys instead of 25 startups.
There is a drawback to this - unfortunately. If you want to end LBC by pressing "e", it will take longer. Namely at the end of the next ask-for-work-block.

Code:

Ask for work... got blocks [426612921-426615288] (2483 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooe <--- here we pressed "e"
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (7.33 Mkeys/s)
Ask for work... got blocks [426626393-426628760] (2483 Mkeys)
<-- here LBC found out
END requested. (Ending this loop) Waiting for children to finish...
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo  <--- here it ends

So max. time from "e" to end is twice the time given in -t


Also, you may see a -d 1 parameter in the process table with the GPU generators.

-d <num> is simply the GPU device to use. If there are several GPUs on the system, this says which one to use. Default is 1

When does one use that? Again, as a LBC user, most of the time you do not need to take care of this, but in case you have a really big iron (say 32 physical CPUs and 4 GPUs), the LBC parameter is called "gdev" aka "GPU device".


Howto - you open 4 windows/terminals:

terminal1: ./LBC --gpu -c 8 -gdev 1
terminal2: ./LBC --gpu -c 8 -gdev 2
terminal3: ./LBC --gpu -c 8 -gdev 3
terminal4: ./LBC --gpu -c 8 -gdev 4

=> you should have 4 LBCs running, each taming 8 generators (8 CPUs + 1 GPU)
used if e.g. 8 CPUs are right to saturate 1 GPU


Rico

Hi,

I just used Ubuntu 14.04.4 and installed fglrx.

Then the normal LBC install.