Large Bitcoin Collider (Collision Finders Pool)

[rico666]

what about https://www.nimbix.net/jarvice/ ?
Allegedly with Pascal GPU support:
"...Nimbix is the only public cloud provider featuring NVIDIA’s latest generation Pascal Tesla P100 GPUs with NVLink, a high-bandwidth, energy-efficient interconnect that allows data sharing at rates 5 to 12 times faster than the traditional PCIe interconnects...."

First off, welcome in the top30. Your GPUauth has been delivered. 

Nimbix looks like similar business to the https://www.leadergpu.com/ link arulbero posted. I wasn't aware of all the "smaller" cloud providers (or let's say: hardware-on-demand) and with these offering newer GPU systems it is my hope that Amazon and Google will not take much longer to offer these too.

LBC doesn't need any fast interconnect between the GPUs it's perfectly parallelizable without any such inter-GPU communication, so NVlink is not a must.


Rico

[1715652740]

1715652740

[1715652740]

1715652740

[1715652740]

1715652740

[1715652740]

1715652740

[1715652740]

1715652740

[SlarkBoy]

test on new machine.

Code:

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 375.39                 Driver Version: 375.39                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1080    Off  | 0000:02:00.0     Off |                  N/A |
| 30%   45C    P2    59W / 180W |   5036MiB /  8114MiB |     63%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 1080    Off  | 0000:03:00.0     Off |                  N/A |
| 27%   40C    P2    60W / 180W |   5036MiB /  8114MiB |     63%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1080    Off  | 0000:81:00.0     Off |                  N/A |
| 29%   44C    P2    59W / 180W |   5036MiB /  8114MiB |     62%      Default |
+-------------------------------+----------------------+----------------------+
|   3  GeForce GTX 1080    Off  | 0000:82:00.0     Off |                  N/A |
| 27%   35C    P2    58W / 180W |   5036MiB /  8114MiB |     63%      Default |
+-------------------------------+----------------------+----------------------+

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                32
On-line CPU(s) list:   0-31
Thread(s) per core:    2
Core(s) per socket:    8
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
Stepping:              1
CPU MHz:               3499.875
CPU max MHz:           3600.0000
CPU min MHz:           1200.0000
BogoMIPS:              6401.29
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-7,16-23
NUMA node1 CPU(s):     8-15,24-31

total 100 Mkeys/s
oclvanitygen speed around 270 Mkeys/s

[rico666]

test on new machine.
...

total 100 Mkeys/s
oclvanitygen speed around 270 Mkeys/s

Very nice.
Please always remember

LBC: 100 Mkeys/s = 200 Maddresses/s
oclvanitygen: 270 Mkeys/s = 270 Maddresses/s (only compressed)

edit:

theoretically, you could distribute the load to your GPUs 3x 10 (or 10+11+11) and let one do other mining stuff.
4 x 64% = ~ 256% -> 144% spare capacity so one full GPU for sure.

I thought about exactly such a configuration (4 x 1080, but Skylake-EX core to feed the GPUs, should come close to 200 Mkeys/s)


Rico

[rico666]

Holy Sh!t - if you look at the "Notable Dates" section of https://lbc.cryptoguru.org/about
you'll see the pool needed about 4 months to crunch its first 100tn keys.

The more we are into #51 search space (only 270 MBlocks to go), the more nervous I get. #51 is a mean bitch for sure - but should we get to the end of the search space without a hit I will have to shoot myself.

On the other hand - that's how I felt with #49 too. 


Rico

[Janu$$]

...
First off, welcome in the top30. Your GPUauth has been delivered. 
...

Thx a lot!

I will use my Radeon GPU as soon as a Windows client or a LBC-Appliance with Radeon GPU support is released.

Have a nice day,
Janu$$

[SlarkBoy]

Very nice.
Please always remember

LBC: 100 Mkeys/s = 200 Maddresses/s
oclvanitygen: 270 Mkeys/s = 270 Maddresses/s (only compressed)

edit:

theoretically, you could distribute the load to your GPUs 3x 10 (or 10+11+11) and let one do other mining stuff.
4 x 64% = ~ 256% -> 144% spare capacity so one full GPU for sure.

I thought about exactly such a configuration (4 x 1080, but Skylake-EX core to feed the GPUs, should come close to 200 Mkeys/s)


Rico

Yeah. But I'm not interested with mining. That's why I came here



We will found bounty or giveaway in a few days.

[unknownhostname]

In the past hour we were 1107156445 keys/s
(at this speed we will have #51 in 2 days)

Rico

Speed is even higher right now ...

Countdown to #51 ...

got more Gkeys generated than the whole pool combined

[hodlcoins]

Just out of interest: what are your costs per day (or so)?

[arulbero]

Please always remember

LBC: 100 Mkeys/s = 200 Maddresses/s
oclvanitygen: 270 Mkeys/s = 270 Maddresses/s (only compressed)

Rico

I think that if oclvanitygen computes 270 Maddress/s, that means that it computes only 135M of x-coordinates (x = coordinates of points of the curve that represent the public keys) and not even a single y-coordinate.
Then the strings: "02x" and "03x" produce 2 addresses ( 2 for each x):

"02x" --> compressed public key
"03x" --> compressed public key


Current LBC generator computes 100 Mkey/s, that means that it computes 100M of x-coordinates + 100M of y-coordinates, then

"04xy" --> uncompressed public key
"02 or 03x" --> compressed public key

Total: 200 Maddresses/s.

Potentially our generator could computes other 2 addresses (not in the same time) from the same x/y, because there are other 2 points related to the same x,y coordinates:

"04x(-y)"  --> uncompressed public key
"03x / 02x" --> compressed public key

Note: sha256 should take half time if only applied to strings like "02x" or "03x" (only 256bit) respect of "04xy" (more than 512 bit).
That's why oclvanitygen seems faster than LBC.

Essentially the cost of compute an uncompressed public key is higher than that related to compressed key (because of y and because of sha256)

[Vyrez]

Pleiades Prototype alpha

Is this the marking of the KNL or another form of "cluster"?

Hmmmm?

[rico666]

Pleiades Prototype alpha

Is this the marking of the KNL or another form of "cluster"?

Hmmmm?

Just yesterday I have thrown the pleiades source code from my Sandbox (I have it still in the repository though), because
with the arulbero-EC arithmetics and my GPU hash160 implementation we have something better.

Having said that, both the KNL as well as the Skylake-EX with their AVX512 engines are a hell of a machine for EC arithmetics.
If anyone has these processors, I can provide a generator binary.
So if anyone is looking for a dedicated machine with quite some key generation performance:

KNL + GPUs (probably too expensive) or Skylake-EX + GPUs (less expensive, but still some bucks)

With these we're getting in the region of 100s of Mkeys/s per machine.


Rico

[SlarkBoy]

Please always remember

LBC: 100 Mkeys/s = 200 Maddresses/s
oclvanitygen: 270 Mkeys/s = 270 Maddresses/s (only compressed)

Rico

I think that if oclvanitygen computes 270 Maddress/s, that means that it computes only 135M of x-coordinates (x = coordinates of points of the curve that represent the public keys) and not even a single y-coordinate.
Then the strings: "02x" and "03x" produce 2 addresses ( 2 for each x):

"02x" --> compressed public key
"03x" --> compressed public key


Current LBC generator computes 100 Mkey/s, that means that it computes 100M of x-coordinates + 100M of y-coordinates, then

"04xy" --> uncompressed public key
"02 or 03x" --> compressed public key

Total: 200 Maddresses/s.

Potentially our generator could computes other 2 addresses (not in the same time) from the same x/y, because there are other 2 points related to the same x,y coordinates:

"04x(-y)"  --> uncompressed public key
"03x / 02x" --> compressed public key

Note: sha256 should take half time if only applied to strings like "02x" or "03x" (only 256bit) respect of "04xy" (more than 512 bit).
That's why oclvanitygen seems faster than LBC.

Essentially the cost of compute an uncompressed public key is higher than that related to compressed key (because of y and because of sha256)

Thanks for the explanation 

[Vyrez]

Hi,

I read a bit about this project at lbc.cryptoguru.org and (addressing anybody and everybody who is doing this) I have a few questions:

1. The "About" section claims that the reason "why" is because somebody said it wasn't possible. That certainly makes sense but once the first "collision" was found the point was proven and there is nothing to prove anymore so why keep going?

2. If a "collision" is found the amount (if any) is "misplaced" (i.e. stolen) into so-called custodial address. The reason for that is because when the discovery is announced somebody else could quickly find the same and steal it. And the reason why the discovery is announced in the first place is.. to prove the point that has already been proven? Again, why this whole thing still keeps going? To prove the point was a valid and perfectly understandable reason. What valid reason is there now?

3. The webpages are full of "rightful owner" this, "rightful ownership" that, but how is this rightful owner supposed to find out about what really happened, i.e. that they in fact weren't robbed, they were just "robbed"? Assuming that every owner of bitcoins in the whole world will somehow magically become aware of some random thread at some random Internet forum and from now on will be anxiously reading it every day for the rest of their lives is just insane. From their point of view their bitcoins were stolen, end of story.
Now this is somewhat an uncharted territory but the same way as manufacturing, sale etc. of some weapons is illegal, and also developing and distributing of software to circumvent copy protection schemes (cracks) is in some jurisdictions illegal, it's not unreasonable to imagine that this software might be deemed illegal in some jurisdictions as well and everybody participating (abetting) might face criminal prosecution. So yet again, since the original goal was already reached is it really worth it to keep going and risk all the possible repercussions?

4. So far only empty or almost empty addresses have been found but what will happen when some reasonable amount (hundreds or thousands BTC) is found? Will the "announcing" and "misplacing" happen again? If somebody has such an amount in one address they are either stupid or they have many similarly loaded addresses. If the latter is the case then aren't you afraid what may happen to you and your dear ones if you piss off the wrong people? I don't see it entirely unrealistic if some angry criminals tracked you down and murdered you and your whole family, and they will most certainly not care one single bit about your "proving the point", "custodial address" etc. bullshit. Internet is not as anonymous as you might think. Is it really worth it to keep doing something that doesn't have any upside, only many downsides?
Maybe you don't value your own life but do you really have the right to put other innocent human beings in grave danger? Maybe you don't have any family, maybe you don't have any friends, but those murderers won't really investigate your personal life, they will just murder you and whoever will be near you at the moment. To make an example of you, to discourage others. Sure the probability of this happening is very low but so is the probability of being shot by a stray bullet, dying in a car/train/airplane fatal accident etc. etc., and yet all those things happen to people on daily basis.

5. When you get a hit do you also test derived addresses, i.e. assuming what you just found might be the top of a HD tree? Since the hit frequency seems to be quite low the slowdown would be negligible.

[rico666]

I read a bit about this project at lbc.cryptoguru.org and (addressing anybody and everybody who is doing this) I have a few questions:

I am willing to answer a stripped down version of your questions.

That is, after you have read this thread where some of your questions are discussed - in length - already.


Rico

[becoin]

I read a bit about this project at lbc.cryptoguru.org and (addressing anybody and everybody who is doing this) I have a few questions:

They've found nothing. You're not allowed to ask such questions. If he sounds like a jerk he probably is a jerk. It's fun to watch how these jerks burn their money. Only interesting thing here is who is funding this "project"?

[rico666]

Good morning guys (and becoin)!

No sign of #51 yet? We're seriously running out of search space - less than 24h left.

Rico

[arulbero]

No sign of #51 yet? We're seriously running out of search space - less than 24h left.

Do we know for sure that there is a key for each bit?

I think we need to have another control (and incentive) system for our work. We cannot run for weeks and get at this point with the doubt that we have lost (in some way) a key.

EDIT: for example, how do you know (and I know) that I made effectively a search between keys "a and b"?  What is the proof of my work?

[rico666]

Do we know for sure that there is a key for each bit?

We don't. It might actually be the reason why #51 is "still standing". Then, on the other hand, the so-called puzzle transaction would have a certain trolling aspect and it would not fulfill the "canary in a coalmine" function as many (including me) suspect it does.

I think we need to have another control (and incentive) system for our work. We cannot run for weeks and get at this point with the doubt that we have lost (in some way) a key.

EDIT: for example, how do you know (and I know) that I made effectively a search between keys "a and b"?  What is the proof of my work?

LBC is certainly not for the faint of heart. It's actually one of the reasons I do not give e.g. GPUauth to anyone who thinks his "willingness to test it" is qualification enough. If you start with LBC you know you're in for the long run. If not, you're just wasting your time and resources.
As for incentives: We will have a nice incentive firework from SlarkBoy soon - where "soon" with LBC means "within a week or so". Clearly, anyone with Attention deficit hyperactivity disorder would be in the wrong place here. 

We're giving found BTCs back to their rightful owners, because that's the morally right thing to do. On the other hand, there are potentionally a million lost BTCs we might be able to recycle. If that's no incentive for someone - I could understand that - then LBC is of course the wrong project for him.


While I do trust the LBC codebase, we're really entering uncharted territory here, so if someone of us doesn't confirm the #51 find, probably no-one will. Except the maker of the puzzle transaction and that one chooses to remain silent.

As for proof of work, read https://lbc.cryptoguru.org/man/tech and https://lbc.cryptoguru.org/man/admin#security
there is a tight challenge-response framework in place to make sure delivered work was really done by the generators and code tampering  to circumvent this has been refuted ever since.

Should we ex-post become aware of any client having cheated, it's one script call to carve this client's work from the "done"-database.


Rico

[arulbero]

While I do trust the LBC codebase, we're really entering uncharted territory here, so if someone of us doesn't confirm the #51 find, probably no-one will. Except the maker of the puzzle transaction and that one chooses to remain silent.

As for proof of work, read https://lbc.cryptoguru.org/man/tech and https://lbc.cryptoguru.org/man/admin#security
there is a tight challenge-response framework in place to make sure delivered work was really done by the generators and code tampering  to circumvent this has been refuted ever since.

I read that pages, but I don't understand what kind of "proof of work" we are talking about.

I mean: I'm interested in a "proof of correct work". This kind of proof needs not only to you, but to everyone is running this client.
My incentive is: I'm sure that I (and we all) are working in the correct way.

My question is: do you check in some way that my work is correct or you check only that I run your code without tampering? It is different.

For example incentive firework from SlarkBoy is good as a control system too. And money is not even necessary to perform this kind of control.


We are searching for something extremely rare. So sentences like:

"I do trust the LBC codebase"
"anyone with attention deficit hyperactivity disorder would be in the wrong place here"

are not soothing to me 

Probably I'm only frustrated, I would really be sorry if we don't hit #51 

[rico666]

I read that pages, but I don't understand what kind of "proof of work" we are talking about.

I mean: I'm interested in a "proof of correct work". This kind of proof needs not only to you, but to everyone is running this client.
My incentive is: I'm sure that I (and we all) are working in the correct way.

I know what you mean. We have no proof of correct work @ runtime. Even less so for every single key.
We have proof of correct work before generators are released. Then, we have "only" proof of work (done).

My question is: do you check in some way that my work is correct or you check only that I run your code without tampering? It is different.

It is. If your machine had e.g. faulty memory or a CPU/GPU that would exhibit faulty computations, your client would effectively pollute the "done"-db. Of course, your client would have to exhibit this behavior after the LBC -x run (which would have to run without errors).

For example incentive firework from SlarkBoy is good as a control system too. And money is not even necessary to perform this kind of control.

Do you have any mechanism in mind? We could issue periodic "LBC -x" runs for the extra paranoid.

We are searching for something extremely rare. So sentences like:

"I do trust the LBC codebase"
"anyone with attention deficit hyperactivity disorder would be in the wrong place here"

are not soothing to me 

Probably I'm only frustrated, I would really be sorry if we don't hit #51 

I think I am pretty well aware of the "rare event" problem. In fact, programming the LBC is like programming a spacecraft: After months of no events, you need it to do the right thing within seconds. I give you that "anyone with ADHD is in the wrong place here" is not soothing. Ok.

But "I trust the LBC codebase" should be.

We have still over 100 tn keys search space, so there is hope. We may also have already a FOUND.txt slumbering somewhere again and the operator slumbering too.  There is still hope. Time for frustration is tomorrow 11 a.m. UTC


Rico