Large Bitcoin Collider (Collision Finders Pool)

[BurtW]

LBC never use base58 encode/decode. I ups its performance too

base58 encode should only use a fraction of resources that hashes use, is it really measurable?

I have a question about this:

0) Calculate K_Public = K_Private * G from the last private key tested

1) Increment to the next K_Private
2) Add G to the K_Public
3) Don't you need to calculate the compressed and uncompressed Bitcoin Addresses here in order to check the block chain for any previous transactions?  Or, are you saying that LBC only checks the unspent outputs list, and it is searched based on the raw compressed and uncompressed keys?
4) Go to 1)

[1714035595]

1714035595

[ZeusLight]

I wish directory.go all key generator had function to generate keys by choosing pattern it seems to be much faster than oclvanitygen but the problem is how to check the matches since u get around 100mb- 1 gb file per second in generatated keys depend on hardware... has anyone tryed to edit ?   

does anyone use brainflayer to generate keys ?  have u solved problem how to make all cores work in one operation ? its a bad thinng u can only use 1 core per operation , wish i could start all 32 cores in same time.

[BurtW]

I wish directory.go all key generator had function to generate keys by choosing pattern it seems to be much faster than oclvanitygen but the problem is how to check the matches since u get around 100mb- 1 gb file per second in generatated keys depend on hardware... has anyone tryed to edit ?   

does anyone use brainflayer to generate keys ?  have u solved problem how to make all cores work in one operation ? its a bad thinng u can only use 1 core per operation , wish i could start all 32 cores in same time.

Your method (sequential search of private keys for a vanity address) is not faster than oclvanitygen.  Just try and find something harder like 1ZeusLight.... and come back here when you find one and tell us how long it took your method to find it.

[itod]

LBC never use base58 encode/decode. I ups its performance too

base58 encode should only use a fraction of resources that hashes use, is it really measurable?

I have a question about this:

0) Calculate K_Public = K_Private * G from the last private key tested

1) Increment to the next K_Private
2) Add G to the K_Public
3) Don't you need to calculate the compressed and uncompressed Bitcoin Addresses here in order to check the block chain for any previous transactions?  Or, are you saying that LBC only checks the unspent outputs list, and it is searched based on the raw compressed and uncompressed keys?
4) Go to 1)

Since there is no source code to look at we can only guess, but keep in mind:
- Since the hashes of the public keys are in the blockhain's transactions as output, you can not guess if that hash is from compressed or uncompressed version of the public key, so you have to calculate both to find the match
- There is no reason to look at only unspent outputs, once you generated the hash it would be reasonable to look at both spent and unspent outputs. It's not the point of the project to sweep money, it's to find as much existing private keys as possible. Are there reports of private keys corresponding with spent outputs in the "found keys" list of the project?

[ZeusLight]

I wish directory.go all key generator had function to generate keys by choosing pattern it seems to be much faster than oclvanitygen but the problem is how to check the matches since u get around 100mb- 1 gb file per second in generatated keys depend on hardware... has anyone tryed to edit ?   

does anyone use brainflayer to generate keys ?  have u solved problem how to make all cores work in one operation ? its a bad thinng u can only use 1 core per operation , wish i could start all 32 cores in same time.

Your method (sequential search of private keys for a vanity address) is not faster than oclvanitygen.  Just try and find something harder like 1ZeusLight.... and come back here when you find one and tell us how long it took your method to find it.

yes if will take unlimited of time  of course.. 

i dont know if it can eb faster by generating by  hex format ive the hex pattern instead of base589 ?

and one thing i wonder, how can thoose addresses be generated : 3734376233323439353666333462343866653264
3333363535363561350A39616263306130393565
6438626461623036336131643932393364356662
3538613839653462336439333164336330383363
3239393236656163366635643635306361313235
6138363938376432663538643531656430373536
3963326138353838366533343333373033646133
6530663636393937663437353432346634353133
656135350A373931323033656164343231366664
33383866663035313938386237620A3536356561
616337346638373361666461376339663730380A
6335636337666637653066363334363262353162
FF747970653A706F696E74657300FFFFFFFFFFFF
343261620B000000000000000000FFFFFFFFFFFF
A000000000000000010000000005F5E100000000

etcc...

[BurtW]

I wish directory.go all key generator had function to generate keys by choosing pattern it seems to be much faster than oclvanitygen but the problem is how to check the matches since u get around 100mb- 1 gb file per second in generatated keys depend on hardware... has anyone tryed to edit ?   

does anyone use brainflayer to generate keys ?  have u solved problem how to make all cores work in one operation ? its a bad thinng u can only use 1 core per operation , wish i could start all 32 cores in same time.

Your method (sequential search of private keys for a vanity address) is not faster than oclvanitygen.  Just try and find something harder like 1ZeusLight.... and come back here when you find one and tell us how long it took your method to find it.

yes if will take unlimited of time  of course..

So, you see then:  1ZeusLight is something that oclvanitygen can do (in a "reasonable" amount of time) but it is too hard for your method and would take a very unreasonable amount of time to find.

Also, if you were really serious about finding 1ZeusLight then you could go pay for the Vanitygen POOL to find it for you.  That way you would have a whole bunch of people working on it in parallel.  The pool would find it even faster.

I asked how long here:  https://bitcointalk.org/index.php?topic=84569.msg25168267#msg25168267

 

[ZeusLight]

I wish directory.go all key generator had function to generate keys by choosing pattern it seems to be much faster than oclvanitygen but the problem is how to check the matches since u get around 100mb- 1 gb file per second in generatated keys depend on hardware... has anyone tryed to edit ?   

does anyone use brainflayer to generate keys ?  have u solved problem how to make all cores work in one operation ? its a bad thinng u can only use 1 core per operation , wish i could start all 32 cores in same time.

Your method (sequential search of private keys for a vanity address) is not faster than oclvanitygen.  Just try and find something harder like 1ZeusLight.... and come back here when you find one and tell us how long it took your method to find it.

yes if will take unlimited of time  of course..

So, you see then:  1ZeusLight is something that oclvanitygen can do (in a "reasonable" amount of time) but it is too hard for your method and would take a very unreasonable amount of time to find.

Also, if you were really serious about finding 1ZeusLight then you could go pay for the Vanitygen POOL to find it for you.  That way you would have a whole bunch of people working on it in parallel.  The pool would find it even faster.

I asked how long here:  https://bitcointalk.org/index.php?topic=84569.msg25168267#msg25168267

 

Yea i see it takes toooo much time.  No im not serious to create this address no meaning to use power for it. thanks for asking .. will be intresting to see what answer will be.   

I try to understand the bitcoin function and it seems the more u work with it the more u will see and more answers u get answered the more questions it gives..  I think there are some addresses with specific patterns that have much more less possibilites of combinations than others. and others hae much more.. as pattern 1C for example i see it every where.


BTW :::  I read about one guy in github claims he lsot hes privkey and trys to find it lol...  and he worte :

"of course nobody can crack private key from address.
but there is a biggest secret in address, which gives you exact location.
means in which numbers you have your key.
but unable to find exact number, researching since a year.
hired many people to solve that math's issue.
paid a lot of money, but nobody is perfect.
if we can resolve that calculation, then we can find exact key.
tried with 100s of private keys.
getting same method, but unable to find, but where the difference coming from."

I have never heard this before , and i dont think its possible to see where the key is located around big int + or does it really existst??  anyone who know more about this.

[BurtW]

I try to understand the bitcoin function and it seems the more u work with it the more u will see and more answers u get answered the more questions it gives..  I think there are some addresses with specific patterns that have much more less possibilites of combinations than others. and others hae much more.. as pattern 1C for example i see it every where.

There are some small anomalies in the probabilities of certain strings in the encoding of the Bitcoin address.  This is of very little interest and of absolutely no practical use.

BTW :::  I read about one guy in github claims he lsot hes privkey and trys to find it lol...  and he worte :

"of course nobody can crack private key from address.
but there is a biggest secret in address, which gives you exact location.
means in which numbers you have your key.
but unable to find exact number, researching since a year.
hired many people to solve that math's issue.
paid a lot of money, but nobody is perfect.
if we can resolve that calculation, then we can find exact key.
tried with 100s of private keys.
getting same method, but unable to find, but where the difference coming from."

I have never heard this before , and i dont think its possible to see where the key is located around big int + or does it really existst??  anyone who know more about this.

You cannot calculate the private key from the Bitcoin address.  Otherwise Bitcoin and every security system on the planet based on ECDSA would be broken.

It is a total waste of his and your time to try to go from the Bitcoin address to the private key by any method.  You should both stop wasting your time on this.

[itod]

BTW :::  I read about one guy in github claims he lsot hes privkey and trys to find it lol...  and he worte :

"of course nobody can crack private key from address.
but there is a biggest secret in address, which gives you exact location.
means in which numbers you have your key.
but unable to find exact number, researching since a year.
hired many people to solve that math's issue.
paid a lot of money, but nobody is perfect.
if we can resolve that calculation, then we can find exact key.
tried with 100s of private keys.
getting same method, but unable to find, but where the difference coming from."

I have never heard this before , and i dont think its possible to see where the key is located around big int + or does it really existst??  anyone who know more about this.

You are wasting your time. Many people that are highly educated in the field designed those algorithms to stop you doing exactly what you are trying to do. Trying to find some trick to beat them is enormous waste of time. You can much better spend it on learning why the system is exactly as it is. Good place to start are Wikipedia articles like this one: https://en.wikipedia.org/wiki/Cryptographic_hash_function. After you read enough you my find some recommended books that my be of interest. Don't waist your time, it's the most precious asset you have.

Edit: lol, posting almost exactly the same thing as BurtW simultaneously.

[ZeusLight]

Yes  thanks for answer.. and its NOT me who trys this .. its a guy in here : https://github.com/saracen/directory.io/issues/10

[speck]

Hey folks.  Huge debate on XRPChat about the credibility of the LBC collisions on the trophy page (https://www.xrpchat.com/topic/12998-is-ripple-vulnerable-to-a-collision-attack/).  For those collisions where money was returned to the original owner, could we see both the owner's and discovered private keys so that we can verify the legitimacy of the collisions?

[itod]

Hey folks.  Huge debate on XRPChat about the credibility of the LBC collisions on the trophy page (https://www.xrpchat.com/topic/12998-is-ripple-vulnerable-to-a-collision-attack/).  For those collisions where money was returned to the original owner, could we see both the owner's and discovered private keys so that we can verify the legitimacy of the collisions?

There were 0 "collisions", just 54 private keys that are meant to be brute-forced by the author of the Puzzle transaction. You can see the found private keys here: https://lbc.cryptoguru.org/trophies.

[speck]

Yes, the majority of those were related to the puzzle, but there were three apparently legitimate collisions on that trophy page where the funds were possibly returned to the owner, thus we might have access to both private keys.  I'm speaking specifically to those.  And I define "collision" as finding a key that hashes to a known address, not necessarily requiring evidence of the original key that generated that address.  I'd rather call something an "unverified collision" than a "non-collision" in the absence of proof, so that the proper scrutiny can be placed on it instead of just dismissed, because the implications of it being legitimate are industrially profound.

[Sukrim]

Just to be clear - what is necessary to show that any meaningful collision happened, is to publish 2 different(!) private keys that create the same address: one key initially used by whoever owns/owned these funds and the new one found by LBC. If you want to troll them, just waste a few spam transactions on a some keys that will be found by the pool soon. Anyone can do that, it just costs a little money.

It would be a waste of time and effort though, especially on such an endeavor...

For those collisions where money was returned to the original owner, could we see both the owner's and discovered private keys so that we can verify the legitimacy of the collisions?

What do you mean, returned? There was no money returned so far...

[speck]

I totally agree that proof of a collision requires two keys, but given the difficulty of procuring such, does it inherently mean we categorically dismiss unverified collisions?  That's rather draconian, particularly since this LBC experiment is the first means by which we can actually verify some of the assumptions the world has placed upon the efficacy of hashing algorithms. 

I swear I've read somewhere that money was returned to someone as a result of this process, but I can't find that reference now.  It does appear that nobody has proffered up those original keys though, based upon what leads LBC's website offer.  Thus, I'm grasping at straws on bitcointalk to see if there is such evidence.  Failing evidence, and instituting the blind faith in the quality of hashing algorithms, it appears as if those purported 3 unverified collisions were fraudulent.  That's hard to digest given the number of people involved, but probably not impossible with a smoke and mirrors show. 

If anyone can add legitimacy to those unverified collisions, please do contribute.

[arulbero]

If anyone can add legitimacy to those unverified collisions, please do contribute.

Nobody knows if the 3 addresses with bitcoins we found so far are collisions. Given that the probability to get a real collision so soon is very very very low, my guess is that they aren't real collision, but only addresses generated by a poor entropy source. In that cases I think we have found simply the "original" private keys used to generate that addresses. The problem is that the owners didn't show up.

[Howery]

Is this LBC real and mathematically provable? How do I participate and get rewarded?

[speck]

Nobody knows if the 3 addresses with bitcoins we found so far are collisions. Given that the probability to get a real collision so soon is very very very low, my guess is that they aren't real collision, but only addresses generated by a poor entropy source. In that cases I think we have found simply the "original" private keys used to generate that addresses. The problem is that the owners didn't show up.

I've been mulling the likelihood of a poor entropy source and this just seems unlikely to me, unless it was intentional.  Someone with a full understanding of entropy would have intentionally sidestepped the common algorithms for generating addresses.  I'm also concerned that this explanation will become the indisputable answer to any collision found.  It may be that the LBC needs to shift its focus away from the 0 - 2^159 range and maybe move up that 160-bit window a few digits just to possibly dissuade these rationalizations.

In summary, here are the possible explanations that I see:

1) the collisions are outright fraudulent
2) they're a product of low entropy key generators (disprovable/provable by moving the LBC test range higher)
3) hashing algorithms are not as well-distributing as we believe them to be, causing multiplicity in working keys per address

[BurtW]

Nobody knows if the 3 addresses with bitcoins we found so far are collisions. Given that the probability to get a real collision so soon is very very very low, my guess is that they aren't real collision, but only addresses generated by a poor entropy source. In that cases I think we have found simply the "original" private keys used to generate that addresses. The problem is that the owners didn't show up.

I've been mulling the likelihood of a poor entropy source and this just seems unlikely to me, unless it was intentional.  Someone with a full understanding of entropy would have intentionally sidestepped the common algorithms for generating addresses.  I'm also concerned that this explanation will become the indisputable answer to any collision found.  It may be that the LBC needs to shift its focus away from the 0 - 2^159 range and maybe move up that 160-bit window a few digits just to possibly dissuade these rationalizations.

In summary, here are the possible explanations that I see:

1) the collisions are outright fraudulent
2) they're a product of low entropy key generators (disprovable/provable by moving the LBC test range higher)
3) hashing algorithms are not as well-distributing as we believe them to be, causing multiplicity in working keys per address

These addresses contained BTC.  LBC has proved beyond a shadow of a doubt that the entropy of the private key used to generate these addresses was extremely, defectively, low.  This has absolutely nothing to do with the hashing algorithm.  Hashing has to do with the calculation of the public Bitcoin address after the private key is selected and after the public key has been calculated from the private key.

Since the private key found was extremely defective the only rational explanation is that the private key found by LBC is the actual private key that was used to generate the public key which was then hashed (by perfectly adequate hashing algorithms) to the public Bitcoin address.  Whether the random number generator was defective or this was done on purpose cannot be established.  BTW people writing code have been known to make mistakes and screw up their random number generators in many ways.

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.

[arulbero]

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.