Topic: Large Bitcoin Collider (Collision Finders Pool) - page 33. (Read 193404 times)

let's proof the strength of BitCoin! LOL!

I'd be down to test on windows 10, ive got a 1080 i could use too if you make a windows build with nvidia gpu support.

More on the technical side, I managed to get the Bloom filter check done on GPU.
Biggest problem was actually the printout in case of a hit.

This raised the keyrate of my notebook from 7.3 Mkeys/s to 8.2 Mkeys/s, while the GPU
is still at 34% usage with 4 CPU cores firing at it.

Needless to say, it works perfectly on my system (24h burn-in with no problems), but
raises a segmentation fault on AWS "hardware".  

Meanwhile, in ECC land, a potential 2.x speedup is on the horizon, which would translate
into a 16 - 24 Mkeys/s on my notebook with the GPU usage at around 70%. We'll see.

Also, I'm falling behind in the top30 from #5 to #7, but I think it's a good thing. 

Rico

Damn, it was that easy??

Go away, you are like a gnat!

Buzz buzzing around the thread driving Rico nuts.

Yes, it is.  28 pages of exceptional blah-blah and not a single collision found.

We're trying to show a private key collision. Actually SHA256 plays the least part in this.

We know because of the 256->160 bit reduction of RIPEMD160, that there are - on average - 2⁹⁶ private keys per address (if you look at both compressed and uncompressed addresses, there actually are 2⁹⁷, but that's just a fun fact)


I don't know if it does prove a point. I don't think so. When I started it, I thought it would be very interesting to actually see a live collision.
Like we all know there must be many (2⁹⁷ is a quite big number) private keys for any address out there. If anything, my point is, that the private key to your bitcoin address does not provide true 256bit security, but thanks to RIPEMD160 only 160bit security - at best. Evidently, when the public key is known, the security of your private key drops to 128bit - at best.

So when you have a bitcoin address with funds on it, and even if you know it has some private key in the - say - 2²⁴⁰ numeric range, the LBC could basically hit an alternate key to it tomorrow - in the 2⁴⁹ numeric range. Probability is low, but not 0.  Also, there is no safe distance. more here: https://lbc.cryptoguru.org/man/theory

Another fun fact is that contrary to BTC mining, we started out with max difficulty and the difficulty is getting lower and lower (thus the probability higher and higher) every day. That's exceptional fun - isn't it? 


Rico

I had to look that up. Yes, at least certain nodes in that network would be suitable. Actually LBC would be a perfect application, because it is parallelizable so well. (Golem has high interconnectivity latencies, making it appear somewhat like the early Beowulf clusters).


One step after another. :-)
In fact, LBC clients will probably undergo a similar evolution like BTC miners did: CPU -> GPU -> FPGA -> ASIC.
We're at the transition phase between CPU and GPU.

But there are already things like "OpenCL for FPGAs" I am aware of. and should we bring the LBC client to a FPGA, I believe for a specialised company it should be technically no big deal to make an ASIC. Still I am not sure anyone would fork out like 3-4 M$ for such a development.


Sort of. Except 0 and -0 :-) you could define -1 as being 110427941548649020598956093796432407238805355338168053038220561162489092
-2 being
110427941548649020598956093796432407238805355338168053038220561162489093
etc.



That's only the LBC appliance for windows users. These days you want to have a linux machine with some Nvidia or AMD GPU installed and then the download is somewhat around 205 MB. And the resulting client is faster.


Rico

Can we use Golem super computer to find a collision? or design ASIC for doing it?
A bit off topic but since you seem like to know things about bitcoin, is it possible to have negative blocks in blockchain? like block 0,1,2 and -0,-1,-2.


Why is this 964MB to download?

Quote from https://lbc.cryptoguru.org/stats

(69.06 Mkeys/s)

LBC isn't specifically looking for #51. These puzzle transaction addresses are merely waypoints. We're looking at everything - including uncompressed addresses (which oclvanitygen does not). So the two addresses with funds we have found are in fact uncompressed ones.


Rico

This is a very interesting project. I have a few very old GPUs that can't mine ZEC/ETH/XMR so I modded the OCLVanitygen to try and find the 51st key from that "32BTC+ Contest" thread.

The problem I had was that if the GPUs are inside a 1x riser then the speed is 50% of what it should be. Only the GPUs in the 4x-8x-16x slots perform up to speed (~20-30MH/s per GPU).


With that speed it would probably take over 3 months just to find the 51st key.

I think the best proposal would be to try and dual mine kind of like the Claymore miner. Where you are mining ETH and with the unused GPU core you can mine to find the 51st key. Like that you wouldn't be losing any speed mining ETH. However running Vanitygen at the same time as ETH/ZEC/XMR greately slow down the mining speed.

You might have misinterpreted what I said, the phrase "attack" was in no way supposed to be an attack on your project, I actually think a successful attack on Bitcoin/SHA256 would be very important and noble of the person showing it in proving that the protocol is no longer effective.

However the project is literally an attempt to find collisions, no? Does it prove a point, and if it does, is it any different to, say, finding a collision in SHA256 using a birthday attack?

Better idea:

http://www.networkworld.com/article/3173995/cloud-computing/google-cloud-debuts-intel-s-latest-skylake-processors.html

We are talking Skylake-EX CPUs here. That's the nifty Skylake cores plus AVX512 engine.

A dedicated AVX512 ECC code could smash everything I know, because your 256bit field arithmetics are suddenly a single machine operation each.

If they pair these CPUs with some GPUs, I may be tempted to try.



Rico

Someone should buy that new 1800x Ryzen chip and run LBC with it...

Also fun fact:


Time since 250 tn: 38 days.

Rico

Please define "regular"  and "us"

Also, would you care to lay out "what we already know"

and finally why you think this is an attack on SHA256.

If you don't know what it adds to BTC development, you probably haven't read anything of the thread in which case it's hard to discuss the matter.

Fun fact: BTC mining is a regular pooled brute force attack.


Rico

Is this just a regular pooled brute force attack? If it is I don't see how it really adds anything to Bitcoin's development or tells us something we don't already know, unless it's trying to use some new novel method of finding collisions: in which case it is less of an attack on Bitcoin, and more of an attack on SHA256 in an attempt to prove it obsolete.

Cpu + GMP library: on your pc you could get 16,7M / 4s or 16,7/ 2s with complement or 16M / 1s with endomorphism.
My function "double_add" now takes 6s on my cpu (on your pc I guess it takes less than 3s), then 4s is a reasonable estimate. If the goal is 15Mkeys/s, CPU + GMP library are enough, otherwise you have to implement an efficient representation of field's elements (like secp256k1 library does) and/or use GPU.

About GPU and multiprecision library:
https://pdfs.semanticscholar.org/d807/b453c7f10bc547971a9344e81a88af934ad0.pdf

Sweet:

Because your GPU is too fast. Or your CPU too slow. Pick one of the explanations ;-)

My CPU-GPU combo uses 34% of the GPU

On Amazon machines, around 8-10 CPU cores are able to saturate a K80 GPU
(that's because both their CPU and GPU are slow)

So yes, there is a HUGE discrepancy between CPU and GPU computational power, so I'm trying to shift more and more load to the GPU.

@freemanjackal

Yes, we are trying to find "for any of the ~9 mio BTC addresses with unspent outputs one of the other 2⁹⁶-1 private keys that should exist.
https://lbc.cryptoguru.org/stats shows the probability to find something within the next 24 hours.
https://lbc.cryptoguru.org/trophies shows what we have found so far


Yes. https://lbc.cryptoguru.org/download  


Rico