I generated an address that already exists
U r kind of a celebrity now. One day I'll create a thread titled "I know a guy who generated an address that already existed".
Topic: I generated an address that already exists (Read 9166 times)
U r kind of a celebrity now. One day I'll create a thread titled "I know a guy who generated an address that already existed".
posting to keep updates on this thread. What actually happened? If the OP made a 50 BTC transaction on that address, shouldn't he remember? Thats a large amount, even in 2012.
The odds for duplicate address aren't "only" 1 in 2^160. It's similar to the birthday paradox, where it only takes 23 people for a 50% probability
Sure, but there are only 365 possible birth dates. Not 2^160
(which is more than 2.74 * 2^157 times as much)The odds are 1 - ((2^160-1)/2^160) * ((2^160-2)/2^160) * ((2^160-3)/2^160) * ((2^160-4)/2^160) * ... repeating for the # of addresses already generated
The answer to this has nothing to do with faith or how people feel, but with a numeric library
Do we actually know what happened?
See the thread. The transaction was already in his wallet (thats what the gettransaction checks for), which wouldn't have been possible if a duplicate address had just been generated. We don't know what exactly happened but there are several other hypothesis which are more consistent with the facts than there being an actual duplicate address generated.E.g. a unclean wallet shutdown made it miss flagging that address as used, thus resulting in it handing it out again, or a mouse mis-targeting resulted in the OP generating an address but then copying another.
Also, now that the newly received coin has been spent we can see that both the new instance and old instance used the same public key (03a97dfbd26061494c9369cd469f8422f7c5f16e4fd6b4da42e42138e711f7fd6f), which means that it's 256 bits involved, not just 160. (E.g. if your hypothesis was a chance collision the probability of that is now 79,228,162,514,264,337,593,543,950,336 times lower than before we knew for sure that he was using the same public keys).
A collision didn't happen here, I'd stake my life on it gladly. With respect to a bad PRNG, things are possible, but the code in Bitcoin-qt has been audited by many people (including myself personally) and that seems unlikely (also, if it were to happen, considering the design I would expect consecutive duplicate addresses and not just one).
If gmaxwell is willing to type something like this in the forum I'm pretty sure he feels so strongly for a reason. I'm breathing a sigh of relief that's for sure!
*Have to say it was also refreshing to see how many veteran's and coredev's jumped on this immediately...gives me a great deal of confidence in bitcoin as a whole given the level of quality and attention to detail being given 24/7.
The odds for duplicate address aren't "only" 1 in 2^160. It's similar to the birthday paradox, where it only takes 23 people for a 50% probability
Sure, but there are only 365 possible birth dates. Not 2^160
(which is more than 2.74 * 2^157 times as much)yes but whos is keeping a tally on current Bitcoin users and of those how many have many instances!~then the bot address exploiter/sniffers,,, double spending hybrids dust generation blah blah blah Gavin will save us!
The odds for duplicate address aren't "only" 1 in 2^160. It's similar to the birthday paradox, where it only takes 23 people for a 50% probability
Sure, but there are only 365 possible birth dates. Not 2^160
(which is more than 2.74 * 2^157 times as much)
The odds for duplicate address aren't "only" 1 in 2^160. It's similar to the birthday paradox, where it only takes 23 people for a 50% probability
Do we actually know what happened?
See the thread. The transaction was already in his wallet (thats what the gettransaction checks for), which wouldn't have been possible if a duplicate address had just been generated. We don't know what exactly happened but there are several other hypothesis which are more consistent with the facts than there being an actual duplicate address generated.E.g. a unclean wallet shutdown made it miss flagging that address as used, thus resulting in it handing it out again, or a mouse mis-targeting resulted in the OP generating an address but then copying another.
Also, now that the newly received coin has been spent we can see that both the new instance and old instance used the same public key (03a97dfbd26061494c9369cd469f8422f7c5f16e4fd6b4da42e42138e711f7fd6f), which means that it's 256 bits involved, not just 160. (E.g. if your hypothesis was a chance collision the probability of that is now 79,228,162,514,264,337,593,543,950,336 times lower than before we knew for sure that he was using the same public keys).
A collision didn't happen here, I'd stake my life on it gladly. With respect to a bad PRNG, things are possible, but the code in Bitcoin-qt has been audited by many people (including myself personally) and that seems unlikely (also, if it were to happen, considering the design I would expect consecutive duplicate addresses and not just one).
this plus the fact that the OP doesn't seem to want to prove he owns the address answers the question for me.
Told you it was a bad idea ;-)
Ah no, this was a couple of weeks ago. Your advice came too late
. 
Another example is brainwallet. Just look at 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T, This address is in hundreds wallets belonging to different people.
Incidentally, don't add this address to your own wallet just to test it. I can assure you this is a really bad idea, because, well. . .just because.
I added it (well I added the correct horse battery staple one but I'm assuming zeroday's talking about it) and lost the ability to listunspent
. pywallet to the rescue…Told you it was a bad idea ;-) And yes, I was also talking about the correct battery horse staple one. The one with the sample sentence from the Brainwallet article in the wiki is pretty similar.
Open up the debug console (help->debug window->console), type in:
gettransaction 5aed0ce301ecd17b237be9bd0dda7fa8fb7e2eb7f453c2ca1f27de160a23c791
If it returns that old transaction then that key was already in the wallet when that transaction hit your client.
When I do this, I see some transaction info. I didn't restore my wallet.
Still, I don't understand what you mean by saying it's always an old address from the keypool.
When I press "New address" button does it generate a brand new address that no one used before?
Bitcoind always keeps a keypool with 100 (?) addresses which is pregenerates. Every time you request a new address it pulls it from this pool and adds a new one to the pool. The idea is to make backups more effective (but deterministic wallets such as Armory uses are way better for this).
Couldn't I hypothetically create a script that systematically generates bitcoin addresses from the pregenerate pool and have the script lookup the generated address to see if the wallet is active with a balance then choose to spend this into a new wallet address?
You could but it would be a huge waste of time and resources.
Another example is brainwallet. Just look at 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T, This address is in hundreds wallets belonging to different people.
Incidentally, don't add this address to your own wallet just to test it. I can assure you this is a really bad idea, because, well. . .just because.
I added it (well I added the correct horse battery staple one but I'm assuming zeroday's talking about it) and lost the ability to listunspent
. pywallet to the rescue… 
Do we actually know what happened?
See the thread. The transaction was already in his wallet (thats what the gettransaction checks for), which wouldn't have been possible if a duplicate address had just been generated. We don't know what exactly happened but there are several other hypothesis which are more consistent with the facts than there being an actual duplicate address generated.E.g. a unclean wallet shutdown made it miss flagging that address as used, thus resulting in it handing it out again, or a mouse mis-targeting resulted in the OP generating an address but then copying another.
Also, now that the newly received coin has been spent we can see that both the new instance and old instance used the same public key (03a97dfbd26061494c9369cd469f8422f7c5f16e4fd6b4da42e42138e711f7fd6f), which means that it's 256 bits involved, not just 160. (E.g. if your hypothesis was a chance collision the probability of that is now 79,228,162,514,264,337,593,543,950,336 times lower than before we knew for sure that he was using the same public keys).
A collision didn't happen here, I'd stake my life on it gladly. With respect to a bad PRNG, things are possible, but the code in Bitcoin-qt has been audited by many people (including myself personally) and that seems unlikely (also, if it were to happen, considering the design I would expect consecutive duplicate addresses and not just one).
Somethings up with this post.
OP said he sent small amount to address but that was timestamped on 10/20 yet the OP is on 10/19? Is that a UTC thing or is he BS'ing?
I suggest he proves to us he controls the private key for this address by publicly making another tx to this of 0.123 and then immediately redeeming.
OP said he sent small amount to address but that was timestamped on 10/20 yet the OP is on 10/19? Is that a UTC thing or is he BS'ing?
I suggest he proves to us he controls the private key for this address by publicly making another tx to this of 0.123 and then immediately redeeming.
Proving he controls the private key proves nothing. As gmaxwell said there is no reason to doubt he owns the address. He could also be trolling us all, having knowingly used the address in the past. Since we're talking about the likelihood of explanations that is yet another one more likely than a collision and also a bad PRNG in Bitcoin-qt I'd say. No offense to the OP of course. Just an objective observation.
OP (or a mod) should change the topic subject to something which more accurately describes what happened here in order to cut down on confusion.
Do we actually know what happened?
I suggest he proves to us he controls the private key for this address by publicly making another tx to this of 0.123 and then immediately redeeming.
Thats not the right way to ask someone to do that, the right way would be to ask them to perform a signmessage (file->signmessage plug in the address, and "this is alikim on bitcointalk", and post the signature and the exact message used). But I don't see any reason to doubt that this address is the OPs. I suspect you have your local timezone set in the forum, his post appears to be >10 minutes after the transaction to me.Why was this moved back out of the technical support area? Is the purpose of this thread to spread (apparent misplaced, see my prior posts) concerns or is it actually to figure out whats up technically?
Somethings up with this post.
OP said he sent small amount to address but that was timestamped on 10/20 yet the OP is on 10/19? Is that a UTC thing or is he BS'ing?
I suggest he proves to us he controls the private key for this address by publicly making another tx to this of 0.123 and then immediately redeeming.
OP said he sent small amount to address but that was timestamped on 10/20 yet the OP is on 10/19? Is that a UTC thing or is he BS'ing?
I suggest he proves to us he controls the private key for this address by publicly making another tx to this of 0.123 and then immediately redeeming.
all address are unique you cant generate the same address
Wrong. All addresses are probably unique, to a high degree of probability and it is entirely possible to generate the same address, especially using a method like brainwallet with a poor passphrase, or using a broken PRNG. There is absolutely nothing other than chance preventing generating the same address, assuming robust PRNG.
all address are unique you cant generate the same address
read op he just did!!!
Jump to: