Bitcoin Forum
June 23, 2017, 03:58:06 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
Author Topic: Large Bitcoin Collider (Collision Finders Pool)  (Read 119220 times)
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 02, 2016, 04:19:52 PM
 #1

The Large Bitcoin Collider (LBC - a.k.a. Collision Finders Pool) is a distributed effort to find private keys to BTC addresses that have funds on them.
See also https://lbc.cryptoguru.org/man/theory#what-we-do
It was using clients that have been developed in the Collision Attack Feasibility Study and later also a derivative of brainflayer (called "HRD-core"). Meanwhile, HRD-core is a complete re-implementation of the BTC address generation process and as such the fastest program on the planet!

Project homepage: https://lbc.cryptoguru.org
Downloads: https://lbc.cryptoguru.org/download
Statistics: https://lbc.cryptoguru.org/stats
Twitter: https://twitter.com/LBC_collider

News:

!!!Visit the New Thread 2.0!!!

  • 2017-03-27: CPU generators with arulbero-ECC released with up to 79% speed increase
  • 2017-03-25: again 250% speed increase with a new CPU/GPU hybrid generator! (Arulbero-ECC)

TODO:

Pending work/development on the LBC components.

Generator (hrd-core):
  • unified generator (one binary for CPU and GPU)

LBC client
  • More elaborated benchmark (not just maximal performance, but adaptive, also in relation to number of CPUs used)
  • Aggregator: manage several generators even on remote servers by just one LBC client (postponed)

LBC server
  • manual updates & extensions (GPU/OpenCL)


----

German thread: https://bitcointalk.org/index.php?topic=1581701.0


all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
1498190286
Hero Member
*
Offline Offline

Posts: 1498190286

View Profile Personal Message (Offline)

Ignore
1498190286
Reply with quote  #2

1498190286
Report to moderator
1498190286
Hero Member
*
Offline Offline

Posts: 1498190286

View Profile Personal Message (Offline)

Ignore
1498190286
Reply with quote  #2

1498190286
Report to moderator
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498190286
Hero Member
*
Offline Offline

Posts: 1498190286

View Profile Personal Message (Offline)

Ignore
1498190286
Reply with quote  #2

1498190286
Report to moderator
2112
Legendary
*
Offline Offline

Activity: 1904



View Profile
August 02, 2016, 04:41:05 PM
 #2

Should something like this be done or not?
Whether you do it or not, I have a perfect name for your project:

cracking_pots@home

.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
georgem
Legendary
*
Offline Offline

Activity: 1260


spreadcoin.info


View Profile WWW
August 03, 2016, 03:28:24 AM
 #3

So, what's your opinion on this? Should something like this be done or not?

Difficult to say, many lifes have been wasted doing much more ridiculous things.

I would start more basic.
I would take an "easy" algo like MD5 and try to learn how to efficiently and quickly create an endless amount of collisions for MD5, and then slowly (veeeeeeery slowly) move to harder algorithms.

Whether you do it or not, I have a perfect name for your project:

cracking_pots@home

 Grin

Haze
Full Member
***
Offline Offline

Activity: 151


View Profile
August 03, 2016, 11:48:16 PM
 #4

Without GPUs, i feel like this will take too long and people would lose interest. Really need to get this working with GPUs instead of CPUs. We really need to decide on a number, say 0.0001% of possible keyspace or something, and see how many collisions are found. We could extrapolate that number to the rest of the available keyspace and determine how feasible and attack would i.e. how much money would need to be spent, what type of equipment, etc.

I think we'll find that it's very infeasible, but I (and presumably you) could not find any actual data on this which is why it makes it interesting!

As for this code being dangerous, i mean i guess, but a quick search on Google shows that tools for hacking loaded keys already exist for free (Hashbasher is shared on this forum) and I haven't heard of anyone ever having coins taken from cold storage. However, if someone did win the cosmic lottery then it would be difficult to prevent them from taking the coins. I have never heard of a cold wallet being drained so I think the chances of this are similar to the chances of finding a collision in the first place.
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 04, 2016, 09:31:44 AM
 #5

I think we'll find that it's very infeasible, but I (and presumably you) could not find any actual data on this which is why it makes it interesting!

This.

~1820 “Rail travel at high speeds is not possible because passengers, unable to breathe, would die of asphyxia.” - Dionysius Lardner
~1950 "Continental drift is impossible ... young scientists shouldn't work on such a stupid idea" - MIT geology courses for undergrads
~1960 "A Proton/Neutron is indivisible" - Physics consensus
~1990 "You cannot have structures smaller than half of the light wavelength." - Physics consensus photolithography
[...]
~2016 "The DAO is safe" - slock.it


Of course one can assume the task is infeasible. And at the moment I have no indication of the contrary. On the other hand not doing something because everyone says it's infeasible seems just wrong. The list above would not seem ridiculous to us today if people were like that. If nothing else, I have learned in the past month a lot of things about efficient computation of the privkey -> pubkey -> *munge* *munge* -> address

That's why I agree with the GPU requirement. If someone could hack oclvanitygen to do certain bidding (throw out a list of uncomressed and compressed addresses for a given privkey-range), that would certainly leverage the project by at least 3 orders of magnitude.

As I started to explore how to efficiently distribute the work on several computers of mine, I did some more hacking towards a user-friendly client. I hope at least those interested in physics do like the name:


Code:
# LBC -h

         LBC - Large Bitcoin Collider v. 0.1

Usage:
    LBC [options]

Options:
    --bench
      Perform a benchmark. This will measure the time to generate one
      block of BTC addresses. Based on that information, it can
      compute the approximate ETA of the job that has been started.

    --cpus <num>
      Set the number of CPUs to delegate address generation to. By
      default only one CPU is used. If you set 0 here, the number of
      CPUs to use is chosen automatically.

    --help/-?
      This help. Options may be abbreviated as long as they are unique.

    --pages <from>-<to>|'auto'
      Give the interval to work on. If 'auto' is given, the optimal chunk
      to work on is fetched.



Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
Haze
Full Member
***
Offline Offline

Activity: 151


View Profile
August 05, 2016, 12:25:18 AM
 #6

What is the issue with applying your code to oclvanitygen instead of vanitygen? From what I understand you're unloading a pre-determined list into RAM and checking to see if any match, right?

Also, i LOVE the name haha Smiley
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 07, 2016, 08:52:35 AM
 #7

I'm using neither vanitygen nor oclvanitygen. Tried to get a grip on the code, but gave up for now.
Instead I hacked a C-Implementation of some bitcoin library, but it's slower than

https://github.com/saracen/bitcoin-all-key-generator

which I am using with slight modifications right now.

I also started to hack a pooling server, so if someone with a 64bit Linux box is interested to try the beta (available - say - next week), drop me a PM with your HW specs. I think we'll try it with 10 beta testers in the 1st wave.


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 10, 2016, 11:21:04 AM
 #8

First successful 'auto' work distribution today!

Started up two clients on two different machines, each of them asked the server for 10 minutes of work, depending on the overall speed of the client (number of CPUs * benchmarked block generation time). Which resulted in client1 geting 50 blocks for its 10 CPUs and client2 got 36 blocks for its 4 - evidently faster - CPUs. Each block is 220 compressed and 220 uncompressed addresses. Checking against all addresses (up to 1 Satoshi) with funds.

Code:
client1 # LBC -p auto -c 10 -t 600
Fetching adequate work... got block interval [100123-100172]
Generating pages from 100123 to 100172 on 10 CPUs.
Reading balances... storable found - using that (faster)...  done.
..............................

at the same time:

Code:
client2 # LBC -p auto -c 4 -t 600
Fetching adequate work... got block interval [100173-100208]
Generating pages from 100173 to 100208 on 4 CPUs.
Reading balances... storable found - using that (faster)...  done.
....................

So within 10 minutes, these two clients checked the equivalent of 704512 pages on directory.io (180355072 addresses so ~ 300k addresses per second).


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 12, 2016, 07:15:51 PM
 #9

I got stats working.  Smiley

Some 4 lonely clients are munging blocks, so let's see if we've tomorrow glorious 37bits of the search space done.

Rico

edit:

Well - almost - some new clients claimed large chunks, so the stats went to 41.x bits of search space, but the server rejected these blocks later for missing POW, so we are at 36.93 bits.

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 18, 2016, 09:32:23 AM
 #10

The "Large Bitcoin Collider" is now in open beta: http://lbc.cryptoguru.org:5000/download

The download link for the 0.803 client should now work for everybody.

Thanks to the beta testers of the closed beta for their help finding and eliminating some bugs.
Installation of the client is still some command line munging, but should be doable for any Linuxer out there.

I'm really curious who will find the 1st bounty (https://blockchain.info/address/1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjqWink

Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
deisik
Legendary
*
Offline Offline

Activity: 1246



View Profile
August 18, 2016, 11:39:25 AM
 #11

The question is, what would we - the bitcoin community - want to achieve with such a task? To prove a collision/brute force attack was at least in one case successful? Lottery by ripping some funds off? Proving bitcoin is indeed hardened against such "attacks" (by ultimately not succeeding)?

This could be beneficial to bitcoin (by not having a single collision coming out of this) - which probably could serve as a tangible reference and in fact might even boost the bitcoin price

The absence of proof is not proof of absence, so I don't think that by not finding a single collision, it could somehow boost the Bitcoin price. On the other hand, the very existence of such a project, its active development and progress in and of itself could be a factor that would negatively affect the Bitcoin price (even if it is not given to succeed)...

And if this project gains a bit of publicity, it might, in fact, have a somewhat depressive effect on the price

rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 18, 2016, 12:18:44 PM
 #12

The absence of proof is not proof of absence, so I don't think that by not finding a single collision, it could somehow boost the Bitcoin price. On the other hand, the very existence of such a project, its active development and progress in and of itself could be a factor that would negatively affect the Bitcoin price (even if it is not given to succeed)...

And if this project gains a bit of publicity, it might, in fact, have a somewhat depressive effect on the price

I thought about that in similar ways, but ultimately came to a different conclusion.

The project is actually destined to find some private keys from time to time. (see https://blockchain.info/address/1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq), but for now all these are placed like breadcrumbs in the search space "before" the pool, so some of the clients will inevitably hit these bounties.

Actually there is no way at the moment the pool wouldn't find the private keys to these breadcrumbs.

As for finding private keys that were not placed intentionally in the pools vicinity: I don't dare to make a guess right now. But I think I came to a different conclusion about the depressive effect on Bitcoin price by the mere existence/operation of this project:

It may be shocking for some/many at 1st glance, but I believe that the longer the pool finds nothing (except the placed bounties), the more positive the effect of the pools existence/operation actually might be. I intend to pursue the project in earnest, so whether there may or may not be some clandestine equivalent, I will certainly do my very best to make sure this open project is at least as effective as some hypothetical clandestine endeavor might be.

The results from this project - well communicated - allow the Bitcoin community to actually have a better shot at risk assessment of this threat vector. Right now, the math says the danger is negligible. Should there at some point be evidence or indication of the contrary, then it's still better to have a project like this for analysis/experimentation of this concrete attack vector.


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
deisik
Legendary
*
Offline Offline

Activity: 1246



View Profile
August 18, 2016, 02:30:49 PM
 #13

It may be shocking for some/many at 1st glance, but I believe that the longer the pool finds nothing (except the placed bounties), the more positive the effect of the pools existence/operation actually might be. I intend to pursue the project in earnest, so whether there may or may not be some clandestine equivalent, I will certainly do my very best to make sure this open project is at least as effective as some hypothetical clandestine endeavor might be.

The results from this project - well communicated - allow the Bitcoin community to actually have a better shot at risk assessment of this threat vector. Right now, the math says the danger is negligible. Should there at some point be evidence or indication of the contrary, then it's still better to have a project like this for analysis/experimentation of this concrete attack vector

Let's cut the crap. If no one specifically searches for collisions, the actual chances to find one are zero. I guess this can hardly be a point of argument. If someone does, nevertheless, search for these, the chances are what they are, and they could be infinitesimally small (they are not), but they are still some positive number greater than zero (the first case)...

So that's what we have when the dust settles and the sun shines in

rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 18, 2016, 04:04:47 PM
 #14

Let's cut the crap. If no one specifically searches for collisions, the actual chances to find one are zero. I guess this can hardly be a point of argument. If someone does, nevertheless, search for these, the chances are what they are, and they could be infinitesimally small (they are not), but they are still some positive number greater than zero (the first case)...

So that's what we have when the dust settles and the sun shines in

Let's cut the crap even more. The project just went into open beta. Let's give it some time for evolution and talk about observations/results then.

Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
DebitMe
Legendary
*
Online Online

Activity: 1680


Crypto-Games.net: Multiple coins, multiple games


View Profile
August 18, 2016, 04:20:43 PM
 #15

Do you plan to release a client for windows downloads?

 

▇▇▇▇
▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇▇
▇▇▇▇▇▇
 
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 18, 2016, 09:14:43 PM
 #16

Do you plan to release a client for windows downloads?

I can try, but have not much experience with Windows. So I would need some really die-hard beta tester for this.

I managed to build a windows version of the Go generate program, and will try to build a standalone Perl App with fatpacker (http://search.cpan.org/~mstrout/App-FatPacker-0.009001/bin/fatpack)

I'll be on vacation soon so I will have some time to meditate on this.  Wink

If anyone feels like testing my trial-and-error of a windows client by the end of the month (or so), feel free to PM me.


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
johan11
Sr. Member
****
Online Online

Activity: 371



View Profile
August 19, 2016, 04:30:30 AM
 #17


How will windows.exe I would like him to test   Grin

Bad times make up strong men, strong men make up good times, good times make up the weak men, where we are now Huh??
rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 20, 2016, 11:52:57 AM
 #18

"There is also a small bounty to be found within the next few blocks: 1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq and when that is found, there will be another one. ;-)"

Should be doable within 24h.

If someone would like to join for the fun of it, I will take my machines down to not hit it accidentally myself. ;-)


Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
deisik
Legendary
*
Offline Offline

Activity: 1246



View Profile
August 20, 2016, 12:00:51 PM
 #19

"There is also a small bounty to be found within the next few blocks: 1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq and when that is found, there will be another one. ;-)"

How great is your "small bounty" actually?

rico666
Hero Member
*****
Offline Offline

Activity: 644


฿ → ∞


View Profile WWW
August 20, 2016, 02:09:34 PM
 #20

"There is also a small bounty to be found within the next few blocks: 1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq and when that is found, there will be another one. ;-)"

How great is your "small bounty" actually?

Since when are Hero Members incapable of browsing blockchain.info?

Rico

all non self-referential signatures except mine are lame ... oh wait ...   ·  Your speed is roughly 11,941,079 keys/s per CPU core. LBC Thread (News)
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!