Bitcoin Forum
November 12, 2024, 04:21:38 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Bitcoin Address Collisions.  (Read 3941 times)
franky1
Legendary
*
Online Online

Activity: 4396
Merit: 4761



View Profile
July 17, 2013, 11:02:06 PM
 #41

i laugh at people who think they are math experts.

there are 2 (followed by 160 zero) possible combinations.. some of you naively believe that if you start at 1 and count upwards it would take 2(followed by 160 zero's) to find a collision.

this would only be the case if the addresses were made in lets say Hex of all F's..

but in reality ITS RANDOM

the addresses can be ANYWHERE between 1 and 2 (followed by 160 zero's).

meaning its just as likely that a randomiser picked 10 as it would pick 100,000,000,000,000.

with an estimated 84mill addresses being used, there is a chance that one of these 'used' addresses is randomised in the low range.

put simply

its random. they are not all clumped up at the far end of the spectrum.

to add to that depending on the degree (amount of significant figures) were used before hashing and converting, can far reduce the potential 'luck'.

this is why i feel the bitcoin foundation are rightly so in adding the new feature for version 0.9 of bitcoin-QT to not require random addresses per transaction.

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
July 17, 2013, 11:07:37 PM
 #42

Nobody said it it is all clumped one end however as pointed out even w/ 1 trillion ASIC address generation machines, each producing (and checking) 1 trillion addresses per second all running non stop for the next 1000 years AND all Bitcoins are evenly divided into the maximum possible addresses with 1 Satoshi each the odds that any machine will find any collision with  funded address in less than 1% in the next 1,000 years.

Sure all public key cryptography is based on "odds".  You could in theory generate a private key in ONE ATTEMPT that matches the one used by google and produce a fake gmail site which validates SSL properly.  However the odds are vanishingly small.  The same thing applies to Bitcoin address collisions.

The odds of anyone finding any collision via brute force in their lifetime is essentially 0%.
Melbustus
Legendary
*
Offline Offline

Activity: 1722
Merit: 1004



View Profile
July 17, 2013, 11:23:40 PM
 #43

...However the odds are vanishingly small.  The same thing applies to Bitcoin address collisions...

Indeed. Probably similar to the odds that you'll be able to walk through a wall suddenly because of quantum fluctuations lining up perfectly.

We live in a probabilistic universe. It's not just bitcoin address generation.

Bitcoin is the first monetary system to credibly offer perfect information to all economic participants.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1026



View Profile
July 18, 2013, 05:15:59 AM
 #44

i laugh at people who think they are math experts.

there are 2 (followed by 160 zero) possible combinations.. some of you naively believe that if you start at 1 and count upwards it would take 2(followed by 160 zero's) to find a collision.

this would only be the case if the addresses were made in lets say Hex of all F's..

but in reality ITS RANDOM

the addresses can be ANYWHERE between 1 and 2 (followed by 160 zero's).

meaning its just as likely that a randomiser picked 10 as it would pick 100,000,000,000,000.

with an estimated 84mill addresses being used, there is a chance that one of these 'used' addresses is randomised in the low range.

put simply

its random. they are not all clumped up at the far end of the spectrum.

to add to that depending on the degree (amount of significant figures) were used before hashing and converting, can far reduce the potential 'luck'.

this is why i feel the bitcoin foundation are rightly so in adding the new feature for version 0.9 of bitcoin-QT to not require random addresses per transaction.

Just FYI, 2160 != 2*10160.

Also, 'random' is a double-edged sword. What you gain by having keys fail to cluster near the far end, you lose by having to check each one.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Rannasha
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


View Profile
July 18, 2013, 07:09:39 AM
 #45

i laugh at people who think they are math experts.
You must laugh at yourself too then.

Quote
there are 2 (followed by 160 zero) possible combinations.. some of you naively believe that if you start at 1 and count upwards it would take 2(followed by 160 zero's) to find a collision.
Queue more laughter. Learn how the power function works please.

Quote
with an estimated 84mill addresses being used, there is a chance that one of these 'used' addresses is randomised in the low range.
2^160 is approximately 10^48 (1 with 48 zeroes). If 84 mill addresses are used (lets say 100 mill for ease of computation), that makes the probability of a new randomly generated address to collide with an existing address equal to 1 : 10^40.

Suppose in the distant future every person in the world (lets say there are 10 B people by then) uses 1000 addresses each, for a total of 10^13 addresses. If every person now has the computer power to generate and test 10^13 addresses per second (that is the size of the entire *huge* global supply of active addresses every second by every person), in one day the odds of finding a collision are approximately 1:10^7, which makes the expected time to find one collision 30000 year at this mindbogglingly high generation rate.

I think we're fairly safe.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!