Bitcoin Forum
November 21, 2018, 05:03:25 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 52 53 54 [55] 56 57 »
  Print  
Author Topic: Large Bitcoin Collider (Collision Finders Pool)  (Read 164418 times)
arulbero
Legendary
*
Offline Offline

Activity: 1090
Merit: 1195


View Profile
December 12, 2017, 08:25:21 PM
 #1081

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.
1542776605
Hero Member
*
Offline Offline

Posts: 1542776605

View Profile Personal Message (Offline)

Ignore
1542776605
Reply with quote  #2

1542776605
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1542776605
Hero Member
*
Offline Offline

Posts: 1542776605

View Profile Personal Message (Offline)

Ignore
1542776605
Reply with quote  #2

1542776605
Report to moderator
1542776605
Hero Member
*
Offline Offline

Posts: 1542776605

View Profile Personal Message (Offline)

Ignore
1542776605
Reply with quote  #2

1542776605
Report to moderator
1542776605
Hero Member
*
Offline Offline

Posts: 1542776605

View Profile Personal Message (Offline)

Ignore
1542776605
Reply with quote  #2

1542776605
Report to moderator
BurtW
Legendary
*
Offline Offline

Activity: 2352
Merit: 1010

All paid signature campaigns should be banned.


View Profile WWW
December 12, 2017, 08:34:43 PM
 #1082

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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
speck
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
December 12, 2017, 08:54:34 PM
 #1083

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
Legendary
*
Offline Offline

Activity: 2352
Merit: 1010

All paid signature campaigns should be banned.


View Profile WWW
December 12, 2017, 10:34:52 PM
 #1084

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 296 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 296 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.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
speck
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
December 12, 2017, 11:10:18 PM
 #1085

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 296 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 296 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
Legendary
*
Offline Offline

Activity: 2352
Merit: 1010

All paid signature campaigns should be banned.


View Profile WWW
December 13, 2017, 01:48:32 AM
 #1086

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 2160 through 2255 range will probably alias to Bitcoin addresses generated by private keys in the 20 through 2159 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 2159 so they will not need to search 2160 through 2255 once they have already searched 20 through 2159.

This is all a moot point anyway as getting to 2159 is beyond their reach at the current time.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
speck
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
December 13, 2017, 04:01:59 AM
 #1087

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 2160 through 2255 range will probably alias to Bitcoin addresses generated by private keys in the 20 through 2159 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 2159 so they will not need to search 2160 through 2255 once they have already searched 20 through 2159.

This is all a moot point anyway as getting to 2159 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 Smiley  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! Smiley
BurtW
Legendary
*
Offline Offline

Activity: 2352
Merit: 1010

All paid signature campaigns should be banned.


View Profile WWW
December 13, 2017, 04:43:57 AM
 #1088

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 296 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?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
speck
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
December 13, 2017, 05:13:32 AM
 #1089

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
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


฿ → ∞


View Profile WWW
December 13, 2017, 09:51:48 AM
 #1090

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Legendary
*
Offline Offline

Activity: 1090
Merit: 1195


View Profile
December 13, 2017, 11:55:44 AM
 #1091

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
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
December 13, 2017, 01:49:07 PM
 #1092

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
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
December 14, 2017, 10:47:30 PM
 #1093

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
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
December 17, 2017, 12:58:42 AM
 #1094

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
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
December 28, 2017, 10:05:37 PM
 #1095

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
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
December 30, 2017, 08:45:20 PM
 #1096

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
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
December 31, 2017, 08:36:08 AM
 #1097

Nice job on this pool, looks very stable and I'm very eager to use this Smiley
holy_ship
Jr. Member
*
Offline Offline

Activity: 85
Merit: 1


View Profile
January 01, 2018, 06:12:39 PM
 #1098

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
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
January 03, 2018, 04:51:59 AM
 #1099

-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
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009



View Profile
January 07, 2018, 08:04:14 AM
 #1100

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!
Pages: « 1 ... 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 52 53 54 [55] 56 57 »
  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!