Large Bitcoin Collider (Collision Finders Pool)

[kknd]

Works LOL

KKND@lbc:~/KKND$ sudo ./LBC --id xxx-secret xxx-c 6 -gpu -gopt lws=256 -p 4021163596-4021164000
GPU authorized: yes
Loop off! Work on blocks [4021163596-4021164000] (424 Mkeys)
Estimated duration: 1m 39.57758075s
oooooooooooooooooooooooo
36af659edbe94453f6344e920d143f1778653ae7:c:priv:000000000000000000000000000000000000000000000000000efae164cb9001+0xe3b
 (10.13 Mkeys/s)

[1715635017]

1715635017

[1715635017]

1715635017

[1715635017]

1715635017

[BurtW]

Hello!!! Is there anybody out there??

...

OPS!!! A bit strange, wright? [NOTE: spelling error, the word here should be "right?"]

...

Great first and only post!  Keep up the good work and someday you will be a Legend in your own mind.

[bigvito19]

Hello!!! Is there anybody out there??

Seems that LBC is scam... or, in other words, if you run LBC on your computer, your computer is running and working for this/these guy/s, and you will see no addresses with bitcoins:

    Seems that rico666 is trying to obtain a new "allbalance file" with the last addresses with bitcoins (https://github.com/znort987/blockparser/issues/65). In the meantime he continues using the same *.blf file, which has the 51, 52 and 53 puzzle addresses included.

Running brainflayer over the current blf file, it detects the addresses with bitcoins:
mmm@Proliant:~/brainflayer$ ./brainflayer -v -I 000000000000000000000000000000000000000000000000000efae164cb9e00 -b funds_h160.blf 36af659edbe94453f6344e920d143f1778653ae7:c:(hex)priv:000000000000000000000000000000000000000000000000000efae164cb9e3c Rate: 253812.80 p/s found: 1/1572864 elapsed: 7.217 s

mmm@Proliant:~/brainflayer$ ./brainflayer -v -I 00000000000000000000000000000000000000000000000000180788e47e3200 -b funds_h160.blf 2f4870ef54fa4b048c1365d42594cc7d3d269551:c:(hex)priv:00000000000000000000000000000000000000000000000000180788e47e326c Rate: 291779.34 p/s found: 1/1048576 elapsed: 3.578 s

mmm@Proliant:~/brainflayer$ ./brainflayer -v -I 00000000000000000000000000000000000000000000000000075070a1a00900 -b funds_h160.blf ef6419cffd7fad7027994354eb8efae223c2dbe7:c:(hex)priv:00000000000000000000000000000000000000000000000000075070a1a009d4 Rate: 345945.88 p/s found: 1/524288 elapsed: 1.732 s

But running LBC in the same address range, it does not detect something:

mmm@Proliant:~/LBC$ ./LBC --id XXX -s XXX -p '#xefae164cb9e00-#xefae164cbffff' Loop off! Work on blocks [4021163596-4021163596] (1 Mkeys) Will use 2 CPUs. (0.67 Mkeys/s) mmm@Proliant:~/LBC$ ./LBC --id XXX -s XXX -p '#x180788e47e3200-#x180788e47fffff' Loop off! Work on blocks [6450351687-6450351687] (1 Mkeys) Will use 2 CPUs. (0.69 Mkeys/s)

OPS!!! A bit strange, wright?


At the same time, you can detect a lot of network activity, so, from my understanding, you computer contacts with the server and sends it the information about the addresses found but nothing is communicated to you...

As I said, SCAM!!!

Btw, why the generator code is not published so in this way we can review it, and, if necessary, compile it at home?

Loooooooooool    

[becoin]

Hello!!! Is there anybody out there??

Seems that LBC is scam... or, in other words, if you run LBC on your computer, your computer is running and working for this/these guy/s, and you will see no addresses with bitcoins:

This project is a scam from the very beginning. So, what? Bitcoin is the nowadays wild west. If you find enough scumbags to form a scam group you're free to participate in whatever scam you like.

[User365]

This should not be possible.  

Your statement is illogical nonsense.  It is easy to calculate that everything being done by the LBC is mathematically possible, they are doing it, and, in fact, you can see with your own eyes that it is really happening.  Wishing something to be not possible when it is obviously possible is pathologically pointless.

All that the LBC and the puzzle transaction are showing/proving is that you should use full entropy private keys.  If you do that then your Bitcoins are totally safe.

No, it is not.
I'm sorry if it is too complex for you.

This should not be possible means that I am fully aware that it is possible but I think it would be better if it was not possible. This means I would be in for a security update.

and NOW it is safe if you use full entropy keys  

Amazing work you are doing here but I think bitcoin needs a security update. This shouldn´t be possible. 

Do you know the basic rules behind Bitcoin? Lol

you man that upgrading would mean hardforking? Well yes

[BurtW]

There are already too many out there. What is going to make yours different from theirs? The entire process is a losing proposition as there is nothing that makes it more successful than just mining and there has yet to be enough power put to the system and that is still a waste as the same power applies to mining would produce the same pay out.

Tell the truth.  You bought your Hero account, right?

[marcus_d79]

Hello ,

after downloading LBC client , runing first LBC -h , then LBC --update, I am not getting blf file. Can't proceed without it. Where I can download it ? Is LBC server under maintenance ?

This does not work as well http://ftp://ftp.cryptoguru.org/LBC/blf/171001-d6e6afe549f661770b8fb1e61a98fe06.blf.bz2

Any help appreciated .

e-mail : marcus_d@gmx.com

Regards,
Mar

[rico666]

Hello ,

after downloading LBC client , runing first LBC -h , then LBC --update, I am not getting blf file. Can't proceed without it. Where I can download it ? Is LBC server under maintenance ?

This does not work as well http://ftp://ftp.cryptoguru.org/LBC/blf/171001-d6e6afe549f661770b8fb1e61a98fe06.blf.bz2

BLF files are under https://lbc.cryptoguru.org/static/blf/ now.

Yeah, the FTP server is borked. Will move everything to HTTPS eventually.

[rico666]

It certainly must be, as the lower bound for an OpenCL implementation of key generation on my Notebook GPU (Quadro M2000M - 640 cores) is 15 Mkeys/s. (As I said, vanitygen does that - inefficiently - computing the compressed public key once you have computed the uncompressed is quite easy). My estimate is, that we should be able to squeeze 20 Mkeys/s out of the Quadro M2000M.

9 Months later...

Squeezing around 29 Mkeys/s with the current implementation.  

[arulbero]

9 Months later...

Squeezing around 29 Mkeys/s with the current implementation.  

And I think that now 5 Mkeys/s is possible with only cpus (Inter Xeon CPU E3-1505M v6 @ 3.00GHz, 4 cores).

...

I have an unpublishable GPU prototype based on vanitygen. It's basically half the speed of vanitygen (which has 15 MKeys/s on my notebook), as it uses 2 passes, one for compressed and one for uncompressed public keys. Also, it requires around 4GB RAM on startup until the AVL data structures are fiddled up. So on my notebook, the GPU prototype needs around 4GB memory on startup and 3.4 GB in GPU RAM and gives around 7MKeys/s.

Almost as fast as the first GPU prototype    

It certainly must be, as the lower bound for an OpenCL implementation of key generation on my Notebook GPU (Quadro M2000M - 640 cores) is 15 Mkeys/s. (As I said, vanitygen does that - inefficiently - computing the compressed public key once you have computed the uncompressed is quite easy).

To make a comparison between vanitygen and our best cpu generator, look at this rate: MAddresses/s.
I made a program (with the last aecc library and the last sha256 and ripemd optimized functions, without any offset constraint on private keys) that generates only compressed keys via cpu without bloom check.

Vanitygen:     15 MAddresse/s (uncompressed keys, on your GPU)

My program: 13.67 MAddresses/s (compressed keys, on my cpus)

[becoin]

It certainly must be, as the lower bound for an OpenCL implementation of key generation on my Notebook GPU (Quadro M2000M - 640 cores) is 15 Mkeys/s. (As I said, vanitygen does that - inefficiently - computing the compressed public key once you have computed the uncompressed is quite easy). My estimate is, that we should be able to squeeze 20 Mkeys/s out of the Quadro M2000M.

9 Months later...

Squeezing around 29 Mkeys/s with the current implementation.  

9 Months later... No success.
9 Years later... Will be the same.

Happy burning of your money!

[rico666]

Vanitygen:     15 MAddresse/s (uncompressed keys, on your GPU)

My program: 13.67 MAddresses/s (compressed keys, on my cpus)

The 29 Mkeys/s I mentioned for the GPU client are 58 MAddrs/s (and 29 of them are harder to compute than what vanitygen does), so it's basically 4 times as fast as vanitygen on the same hardware.

This may look better in vanitygen's favor on fast GPUs, but we'll get there too.

Fortunately becoin volunteered to pay for further development:
https://lbc.cryptoguru.org/crowdfunding
I wonder how much he will give.

[Gleb Gamow]

Hello!!! Is there anybody out there??

Seems that LBC is scam... or, in other words, if you run LBC on your computer, your computer is running and working for this/these guy/s, and you will see no addresses with bitcoins:

LBC is NOT a scam because they went outta their way in dissing me who went outta my way in exposing them as a scam. That outta the way, now get outta their way while they ... FUCK ME! I forgot what I was gonna say. Well, whatever it was, I assure you it was epic.  

[rico666]

Unfortunately Glue Gamete is as ignored in my view as is becoin, so I hope to assume he also volunteered to make a significant Crowdfunding contribution?

[nlhuy0905]

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.

[BurtW]

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.

You and your opinion are totally wrong.  The entire purpose of this project is to see just how quickly sequential addresses can be generated in order to sequentially search and find addresses that currently contain or have previously contained Bitcoin.  Since that is the purpose there is no reason to under report the number of addresses that have previously contained Bitcoins.  With the exception of Bitcoins that have been purposefully placed in low entropy addresses, like the puzzle transaction, or Bitcoins that have been inadvertently placed in low entropy addresses, for example from a defective random number generator, this project will never find any Bitcoins that have been properly stored at Bitcoin address generated from an adequate source of entropy.  But again, that is not the purpose of the project.

Also, your comment "we cannot rely on this sort of luck" indicates you have absolutely no idea how this project works.  It is sequentially creating all possible addresses starting at private key 0x1.  There is no luck involved.

Oh wait, I just ranted at another f!@#ing account farmer that will never be back to this thread.  Oh well...

Hello!!! Is there anybody out there??

Seems that LBC is scam... or, in other words, if you run LBC on your computer, your computer is running and working for this/these guy/s, and you will see no addresses with bitcoins:

LBC is NOT a scam because they went outta their way in dissing me who went outta my way in exposing them as a scam. That outta the way, now get outta their way while they ... FUCK ME! I forgot what I was gonna say. Well, whatever it was, I assure you it was epic.  

Bruno, you crack me up.  Blaze on dude.

[rico666]

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.

What is wrong with "hook-find"?

https://lbc.cryptoguru.org/man/user#hooks

[monsanto]

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.

You and your opinion are totally wrong.  The entire purpose of this project is to see just how quickly sequential addresses can be generated in order to sequentially search and find addresses that currently contain or have previously contained Bitcoin.  Since that is the purpose there is no reason to under report the number of addresses that have previously contained Bitcoins.  With the exception of Bitcoins that have been purposefully placed in low entropy addresses, like the puzzle transaction, or Bitcoins that have been inadvertently placed in low entropy addresses, for example from a defective random number generator, this project will never find any Bitcoins that have been properly stored at Bitcoin address generated from an adequate source of entropy.  But again, that is not the purpose of the project.

<snip>

Any ballpark estimate of the percentage of current bitcoin addresses with say, more than 1 btc, that have inadvertent low entropy?

[BurtW]

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.

You and your opinion are totally wrong.  The entire purpose of this project is to see just how quickly sequential addresses can be generated in order to sequentially search and find addresses that currently contain or have previously contained Bitcoin.  Since that is the purpose there is no reason to under report the number of addresses that have previously contained Bitcoins.  With the exception of Bitcoins that have been purposefully placed in low entropy addresses, like the puzzle transaction, or Bitcoins that have been inadvertently placed in low entropy addresses, for example from a defective random number generator, this project will never find any Bitcoins that have been properly stored at Bitcoin address generated from an adequate source of entropy.  But again, that is not the purpose of the project.

<snip>

Any ballpark estimate of the percentage of current bitcoin addresses with say, more than 1 btc, that have inadvertent low entropy?

Zero or maybe imperceptibly and immeasurably just above zero.

[monsanto]

Imho we must find a way so client operators get notified, we cannot rely on this sort of luck and quite honestly, I start to believe the pool has found way more addresses than we currently know of.

You and your opinion are totally wrong.  The entire purpose of this project is to see just how quickly sequential addresses can be generated in order to sequentially search and find addresses that currently contain or have previously contained Bitcoin.  Since that is the purpose there is no reason to under report the number of addresses that have previously contained Bitcoins.  With the exception of Bitcoins that have been purposefully placed in low entropy addresses, like the puzzle transaction, or Bitcoins that have been inadvertently placed in low entropy addresses, for example from a defective random number generator, this project will never find any Bitcoins that have been properly stored at Bitcoin address generated from an adequate source of entropy.  But again, that is not the purpose of the project.

<snip>

Any ballpark estimate of the percentage of current bitcoin addresses with say, more than 1 btc, that have inadvertent low entropy?

Zero or maybe imperceptibly and immeasurably just above zero.

damn I should have said total number of