Large Bitcoin Collider (Collision Finders Pool)

[BurtW]

The private key is the private key.  I am having a hard time understanding how this has anything to do with hashing or collisions, whether "fraudulent" or not, whatever that means.

If we found a private key capable of unlocking funds on a address, there would be only 2 possibilities to be sure we have found a real collision:

1) the owner of the address sends us its private key, and that key is different from ours

2) the address has already exposed its public key on the blockchain (there is a transaction from that address to another); in this case it would be trivial to verify if our public key and that public key are different or not. We could have a collision even if we don't know the other private key.

In each case by "collision" we mean 2 different public keys (and then 2 different private keys) with the same hash160.

Yes, I understand that.  I guess what I am really trying to say is that with the entropy of the private key found by LBC so obviously defective the likely and obvious scenario is that this was a defective RNG or bug in the private key generation.  So, why all the fuss over this as a possible collision?  Makes no sense to me.  Just sounds like a bunch of people off on a tangent.

[1713888048]

1713888048

[speck]

Yes, I understand that.  I guess what I am really trying to say is that with the entropy of the private key found by LBC so obviously defective the likely and obvious scenario is that this was a defective RNG or bug in the private key generation.  So, why all the fuss over this as a possible collision?  Makes no sense to me.  Just sounds like a bunch of people off on a tangent.

Fraudulent was a reference to the credibility of the posted collisions on the LBC trophy page.  Someone may have just posted their known keys, though this strikes me as very unlikely

I'm merely suggesting that your hypothesis isn't the only hypothesis.  It may be that hashing algorithms don't uniformly distribute the results across the full spectrum of possible hash values, leading to the notion that a hash can have multiple keys.  If we shifted the LBC's testing range into a higher range of bits, then any further unverified collisions would support the hypothesis that the hashing algorithm is faulty.  At this time, we have no way to distinguish low-entropy key artifacts from hashing algorithm artifacts.  You can choose to deny my hypothesis in blind faith, but the SHA-256 algorithm for example, is a gnarly beast with lots of gears and levers; would be pretty hard to ascertain the biases it introduces into the results.  

If there's any way to compel the LBC to shift to a different range of keys, we could possibly put this to rest

[BurtW]

Fraudulent was a reference to the credibility of the posted collisions on the LBC trophy page.  Someone may have just posted their known keys, though this strikes me as very unlikely

The LBC is not posting "collisions".  It is posting the private keys that contain or contained BTC.  Since they started at private key 1 and are iterating sequentially through the private keys your notion of "fraudulent" makes no sense.  Yes, someone can send BTC to an address created from a private key in the range being searched by LBC - and people have.  I would not consider that fraud by any definition I know.  LBC is not claiming to have found a collision.  They are only claiming to have found used addresses in the lower private key range they are searching.
 

I'm merely suggesting that your hypothesis isn't the only hypothesis.  It may be that hashing algorithms don't uniformly distribute the results across the full spectrum of possible hash values, leading to the notion that a hash can have multiple keys.  

If by hash you mean a Bitcoin address then there are approximately 2⁹⁶ private/public key pairs that map to every Bitcoin address.  This is a well known fact.  So, yes every hash has multiple keys, in fact approximately 2⁹⁶ keys.

If we shifted the LBC's testing range into a higher range of bits, then any further unverified collisions would support the hypothesis that the hashing algorithm is faulty.  At this time, we have no way to distinguish low-entropy key artifacts from hashing algorithm artifacts.  You can choose to deny my hypothesis in blind faith, but the SHA-256 algorithm for example, is a gnarly beast with lots of gears and levers; would be pretty hard to ascertain the biases it introduces into the results.

If by "in blind faith" you mean "trust in the math of very large numbers, the laws of probability, and the integrity of SHA-256" then I do deny your hypothesis that this is anything other than a simple bad RNG, a code bug, or someone screwing around and putting BTC there to be found by LBC or something similar.

If there's any way to compel the LBC to shift to a different range of keys, we could possibly put this to rest

Probably not.  They are pretty set in their ways - their ways being start with private key 1, then try 2, then try 3, etc.

[speck]

The LBC is not posting "collisions".  It is posting the private keys that contain or contained BTC.  Since they started at private key 1 and are iterating sequentially through the private keys your notion of "fraudulent" makes no sense.

The LBC is publicly stating its mission to unlock coins in blockchains, therefore they're naturally in pursuit of "collisions".  You can reframe this precise pursuit as "iterating through the possible keys", but that is merely the literal action that fulfills the purpose of finding collisions.  Why is it necessary to resist the notion of 'collision searching' when it's merely a different spin on 'pursuing keys for known addresses'?  What they've posted are theoretical collisions by their own definition.  They state that they are looking for alternate keys in the 0 - 2^159 range to open addresses that may have been generated in the 2^160-up range.  If that isn't collision-seeking then I don't know what is. 

As to my "fraudulent" assertion, without the low-entropy addresses, it's supposed to be statistically damn-near impossible to find even 'one' key that could unlock any of the addresses they seek.  Therefore, the claiming of THREE working keys purports to one of the three hypothesis' I stated, one of them being that they were already known keys, which is fraud with the intent of portraying the LBC as more effective than it really is.  I'm not saying they are indeed lying about it, but this option can't be removed from the table.

If by hash you mean a Bitcoin address then there are approximately 2⁹⁶ private/public key pairs that map to every Bitcoin address.  This is a well known fact.  So, yes every hash has multiple keys, in fact approximately 2⁹⁶ keys.

ok, we agree on that, but you're also assuming that all hashes can be a product of a key, where I'm suggesting that we don't know just how many of the 'potential' hashes actually have a key.  In other words, the realm of hashes may be much smaller than we realize and this could be why so many keys appear to be working.

If by "in blind faith" you mean "trust in the math of very large numbers, the laws of probability, and the integrity of SHA-256" then I do deny your hypothesis that this is anything other than a simple bad RNG, a code bug, or someone screwing around and putting BTC there to be found by LBC or something similar.

'blind-faith' refers to someone believing that an algorithm does what you're told it will do, without actually understanding every nuance of the algorithm.  Forgive me if I assume that you couldn't speak to the inner-workings of SHA-256, because without a doubt, most people couldn't begin to follow the methodology and motivations buried in it.  That being said, encryption history is littered with failed algorithms because someone found a flaw in it, completely neutralizing its efficacy.  Your denying of my hypothesis follows a very long line of people that were convinced that the status quo was also unbeatable, but were wrong.  You may be right, for now.

If there's any way to compel the LBC to shift to a different range of keys, we could possibly put this to rest

Probably not.  They are pretty set in their ways - their ways being start with private key 1, then try 2, then try 3, etc.

Undoubtedly in pursuit of the low entropy targets.

[BurtW]

They state that they are looking for alternate keys in the 0 - 2^159 range to open addresses that may have been generated in the 2^160-up range.  If that isn't collision-seeking then I don't know what is.

Almost all Bitcoin addresses generated from private keys in the 2¹⁶⁰ through 2²⁵⁵ range will probably alias to Bitcoin addresses generated by private keys in the 2⁰ through 2¹⁵⁹ range by the definition of Bitcoin addresses.  So, no, they are not looking for "collisions" in that sense you suggest.  They just know they will find almost all the possible Bitcoin addresses by the time they reach 2¹⁵⁹ so they will not need to search 2¹⁶⁰ through 2²⁵⁵ once they have already searched 2⁰ through 2¹⁵⁹.

This is all a moot point anyway as getting to 2¹⁵⁹ is beyond their reach at the current time.

[speck]

They state that they are looking for alternate keys in the 0 - 2^159 range to open addresses that may have been generated in the 2^160-up range.  If that isn't collision-seeking then I don't know what is.

Almost all Bitcoin addresses generated from private keys in the 2¹⁶⁰ through 2²⁵⁵ range will probably alias to Bitcoin addresses generated by private keys in the 2⁰ through 2¹⁵⁹ range by the definition of Bitcoin addresses.  So, no, they are not looking for "collisions" in that sense you suggest.  They just know they will find almost all the possible Bitcoin addresses by the time they reach 2¹⁵⁹ so they will not need to search 2¹⁶⁰ through 2²⁵⁵ once they have already searched 2⁰ through 2¹⁵⁹.

This is all a moot point anyway as getting to 2¹⁵⁹ is beyond their reach at the current time.

I just don't understand what it is that people here think "collision" means.  The definition is precisely what you typed above.  Two keys that generate the same hash.  Does the euphemism of collision not register at all?  The address a found key opens was obviously created by another key right?  So if they can open an address then two keys exist!  Hence, collision   Sure, maybe they hit the actual key on some low-entropy addresses, but their mission statement isn't to find these low-entropy addresses, they are looking for duplicate keys.  Collisions!

[BurtW]

The address a found key opens was obviously created by another key right?

No, I believe that the private key found is identical to the private key originally used, hence this is not a collision.  LBC just found the original private key.

I think we both agree that it is obviously possible for two keys to hash to the same Bitcoin address.  In fact, as we agreed, there are approximately 2⁹⁶ keys for every address so of course, yes, collisions are possible.

Where we disagree is:  you think that these private keys that were found by LBC are possible collisions.  I do not.

You can waste your time trying to prove that it was a collision.  It is your time to waste.  I am perfectly happy with the simple explanations I have given.  Your position (that they are collisions) is highly improbable.  My position is highly probable.  

How about we talk more specifically.  Exactly which private keys do you think are possible collisions?

[speck]

The address a found key opens was obviously created by another key right?

Where we disagree is:  you think that these private keys that were found by LBC are possible collisions.  I do not.

...

How about we talk more specifically.  Exactly which private keys do you think are possible collisions?

No, actually, I have multiple theories and I'm not married to any of them.  If the SHA-256 algo is indeed well-distributed, then yes, they are probably low-entropy original keys.  If SHA-256 is not well-distributed, then some or all of those non-puzzle hits could be collisions.  You're not going to tell me that you know for certain that SHA-256 is well-distributed.

We will never know....

More importantly, the crux of this conversation started with the 'intent' of the LBC, and that is very clearly to find collisions

[rico666]

No, actually, I have multiple theories and I'm not married to any of them.  If the SHA-256 algo is indeed well-distributed, then yes, they are probably low-entropy original keys.  If SHA-256 is not well-distributed, then some or all of those non-puzzle hits could be collisions.  You're not going to tell me that you know for certain that SHA-256 is well-distributed.

We will never know....

Never say never...

What makes you pinpoint this to the well-distributedness of SHA-256? Why is everyone neglecting the poor RIPEMD-160? It needs attention too!

@RIPEMD160 Come here darling. No one loves you but me.

[arulbero]

If SHA-256 is not well-distributed, then some or all of those non-puzzle hits could be collisions.  You're not going to tell me that you know for certain that SHA-256 is well-distributed.

We will never know....

Never say never...

What makes you pinpoint this to the well-distributedness of SHA-256? Why is everyone neglecting the poor RIPEMD-160? It needs attention too!

@RIPEMD160 Come here darling. No one loves you but me.

The well-distributedness of ripemd160 is much more important! It is the last time we cross the deck.

A curious fact: even if sha-256 was well-distributed, the 2^257 public keys (compressed and uncompressed) would "hit" about 86.5% of the 2^256 possible 256 bit strings  (output of sha-256). From the compressed public keys we use today (2^256) we could get with sha-256 only the 63% of the possible 256 bit strings.

That means that some (very few) collisions happen already at sha-256 level.

[speck]

No disrespect to RIPEMD-160, I'm just a one-hash kind of guy

I believe that the findings of the LBC are too easily dismissed as low-entropy original key hits, and the real benefit of this project is being lost.  If full entropy key ranges were explored (all bits utilized in the keys), then any collisions discovered would portend to a weakness in the hash's distribution, and hence blockchains would be considerably more exposed than currently thought.  Is this not the overarching intent of the LBC?  Or is it to chase low-hanging fruit while spooking people with the notion that addresses are crackable?

[Firebox]

Hi, folks!
Please help to noob ))
What is the proper command to send a secret to server? Give me an example please.
Trying this
./LBC -no_update -cpus 7 -secret ******,
but get
Invalid secret format/characters.

PS Secret is given for the first time.

[JustMe2017]

First time using this also and having a hard time finding the info anywhere.

I manually downloaded everything to get it working, checked the updates and it's all up to date, whenever I run the LBC -x it works just fine ut when I run it for real it always fails saying one of several different error messages which randomly seem to rotate each time I try.

I have tried adding an --id I've tried adding --secret in a variety of different ways as described in the manual and other ways to test, this is the first time using this, no modifications to any files or anything but it always says error that the server doesn't like us with Answer, secret is wrong or malformed request or perm withdrawn or challenge failed or error 0x567 or gen checksum.

Nothing seems to work and I have no idea why.

Any ideas to make this work?

[Gantz87]

First time using this also and having a hard time finding the info anywhere.

I manually downloaded everything to get it working, checked the updates and it's all up to date, whenever I run the LBC -x it works just fine ut when I run it for real it always fails saying one of several different error messages which randomly seem to rotate each time I try.

I have tried adding an --id I've tried adding --secret in a variety of different ways as described in the manual and other ways to test, this is the first time using this, no modifications to any files or anything but it always says error that the server doesn't like us with Answer, secret is wrong or malformed request or perm withdrawn or challenge failed or error 0x567 or gen checksum.

Nothing seems to work and I have no idea why.

Any ideas to make this work?

Logfile from LBC make it more simple...

Hi, folks!
Please help to noob ))
What is the proper command to send a secret to server? Give me an example please.
Trying this
./LBC -no_update -cpus 7 -secret ******,
but get
Invalid secret format/characters.

PS Secret is given for the first time.

$ LBC -id Hoolakawoola -s x:somesecret

x is a random old secret and somesecret the new given one...
https://lbc.cryptoguru.org/man/user

[ZafotheNinja]

So, being new here in general as well as this thread I may just be ignorant but I have to ask.

If the goal of this project is to find collisions and the best way to find one is if an "owner" comes forward claiming their wallet was stolen by LBC, then why is the LBC only searching addresses that have balances "up to 1 Satoshi"? Especially given that the average bitcoin holder has a balance of 2 bits (0.0002 btc)?

I get the whole "we are searching for collisions, not trying to crack wallets" but it seems to me that you get just as many abandoned wallets with small balances as you do with large balances and that the ideal search space should be in the average balance range of 2 bits. (For that matter I would crank the number up to the 20-150 bit range considering that a guy with $20 or more in it is a lot more likely to seek out why his btc have gone missing)

I have read up to page 11 on this thread as well as have used the search box up there and Google, however I have yet to come to an answer for this seemingly obvious question.

Edit: According to the "trophies" page the balances are 0.1 bits (0.00001 btc) not 1 Satoshi? Regardless the question remains the same.

Edit#2: Wowza, just realised how many noobs just posted above me. It's like attack of the noob army over here. Just read through the ENTIRE THREAD still coming to no true answer, but it seems the  search area is bigger then I thought, topping at almost 79 bits (So far). Still, the question remains relevant in why addresses with so few funds are in the search space.

Also, on page ~40 someone asks if this program will work for cracking a single address. It is briefly explained that yes it would but it would be slower to do so. 1/~15m of the speed. Could you explain in simple terms why? I would have thought that doing so would increase the speed by a multiple of ~15m in terms of raw keyspace searched. (Eg, the overall chance of finding a key is unaffected and the overall search speed is in unaffected yet the chance of finding a key to a specific address increases. Effectively searching 1/15m'th of the work 15m x faster.)

Address = Public Key = BTC Wallet
Key = Private Key

[Iridian]

Nice job on this pool, looks very stable and I'm very eager to use this

[holy_ship]

Also, on page ~40 someone asks if this program will work for cracking a single address. It is briefly explained that yes it would but it would be slower to do so. 1/~15m of the speed. Could you explain in simple terms why?

Right now bloom filter with ~20mln addresses with funds is more than 500MB and it takes precious RAM from every GPU process.
I suppose switching to 1 address (or say 5000 really abandoned wallets) would RAISE speed in several times.
But unfortunately, the project is looking for all addresses.

The probability to find ANY address would be 15mln times lower.

The probability to find EXACT address would be the same.

[ZafotheNinja]

-snip-

Right now bloom filter with ~20mln addresses with funds is more than 500MB and it takes precious RAM from every GPU process.
I suppose switching to 1 address (or say 5000 really abandoned wallets) would RAISE speed in several times.
But unfortunately, the project is looking for all addresses.

The probability to find ANY address would be 15mln times lower.

The probability to find EXACT address would be the same.

So less ram used + less addresses to check against = Less work done faster



So Case #1:

15-20m addresses; the probability (in 1 Year) to find any working key to any address within the keyspace = "X" at "Y" keys tried per second.

Case #2:

1 address; the probability (in 1 Year) to find any working key to the single address in the keyspace = "A" at "Z" keys tried per second, where "Z">"Y" by some multiple.



In the scope of LBC it's obviously slower this way (2^160/1 or 2^160/15m), but by what amount is "Z" > "Y", and is "A" greater, less or equal to "X"? If it takes roughly 1/3 of a year to find a key in the full address set (I know, probably shear luck) then how long would it take to find a working key for a specific address?

[becoin]

If it takes roughly 1/3 of a year to find a key in the full address set (I know, probably shear luck) then how long would it take to find a working key for a specific address?

Walk down the street, watch your legs and you'll have greater probability to find some lost coin. Good luck!

[yangxin325]

After i entering the username——osboxes, why i can't enter the password, use the keyboard, the screen does not display any character.
what is wrong with it?