How is this address possible?

[SgtSpike]

Base58 discludes 0oiL, so how is an address like this one possible?
http://blockexplorer.com/address/1BitcoinEaterAddressDontSendf59kuE

[SgtSpike]

This one too...
http://blockexplorer.com/address/1Boxo846yTDLHgKM94aYseHBnCjJ4eYbzb

[bji]

The coins sent to that address are gone forever as it is not possible to claim them, because it is not possible to produce a public key that will hash to that value in base58.

The transaction was perfectly valid - it sent bitcoin to an invalid address, that's all.

I find it strange that block explorer shows that string for the address though; shouldn't it be formatting the binary of the bitcoin address hash in base58 before printing it?  base58 definitely does not include some of the characters in that printed address, as you have pointed out.  Very strange.

[SgtSpike]

So the only check for the client to make a transaction is the checksum at the end of the address?  As long as the checksum matches, then it will allow the transaction to be processed?

Interesting...

[SgtSpike]

I've got a couple addresses in my wallet that have both L and o. What's going on there?

o.O

[EricJ2190]

Neither of those are invalid. Bitcoin's base58 skips '0', 'O', 'I', or 'l'. Characters 'o', 'i', and 'L' are fine.

Code:

static const char* pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";

[SgtSpike]

Neither of those are invalid. Bitcoin's base58 doesn't allow '0', 'O', 'I', or 'l'. Characters 'o' and 'L' are fine.

Code:

static const char* pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";

Ahhhhh, makes a whole lot more sense.  Thanks for straightening that out for me (us).

[Alex Beckenham]

Base58 discludes 0oiL, so how is an address like this one possible?
http://blockexplorer.com/address/1BitcoinEaterAddressDontSendf59kuE

Maybe the EFF should send their donations there.

The end of the address even seems to be sending them a special message: f59k u EFF

[Samantha2011]

So does someone actually own the 1BitcoinEaterAddressDontSendf59kuE address?

If so, how hard is it to make your own address like that? 

[EricJ2190]

So does someone actually own the 1BitcoinEaterAddressDontSendf59kuE address?

If so, how hard is it to make your own address like that? 

I am sure nobody owns that address, but people have generated simpler vanity addresses.

See http://forum.bitcoin.org/index.php?topic=1387.0

[Samantha2011]

So does someone actually own the 1BitcoinEaterAddressDontSendf59kuE address?

If so, how hard is it to make your own address like that? 

I am sure nobody owns that address, but people have generated simpler vanity addresses.

See http://forum.bitcoin.org/index.php?topic=1387.0

Thanks. I was thinking the encryption was broken for a second. 

[ByteCoin]

This may be an appropriate thread to mention that the the "checksum" at the end of an address does not effectively prevent single character errors or transpositions.

For instance https://blockexplorer.com/search/1ByteCoin shows that

Code:

1ByteCoinAddressesMatch1kpCWNXmHKW
1ByteCoinAddressesMatch1kpCxNXmHKW

are both valid addresses even though they only differ by one character.

Similarly, the valid addresses

Code:

1ByteCoinAddressesMatchcNN781jjwLY
1ByteCoinAddressesMatchcNN718jjwLY

only differ by one transposition.

ByteCoin

[SgtSpike]

Question: What is the checksum calculation?

[Pieter Wuille]

first or last 32 bits of the double sha256 checksum of everything before.

[bji]

first or last 32 bits of the double sha256 checksum of everything before.

Bitcoin addresses are 160-byte hashes of a public key, and are represented in base-58, which is an ASCII encoding that does not use 0, O, I, and l, to avoid confusion.

The addresses that ByteCoin is talking about were clearly not produced by hashing a public key.  The chances of producing recognizable text like that in a bitcoin address are so incredibly small as to be practically impossible.

So those addresses were just typed in by somebody and the hash applied to the end (which is the random-looking stuff at the end).

ByteCoin is right in that the addresses are valid and contain a single transposition which makes the argument that bitcoin addresses are very difficult to mistype because they use a checksum seem wrong.

[ByteCoin]

The addresses that ByteCoin is talking about were clearly not produced by hashing a public key.  The chances of producing recognizable text like that in a bitcoin address are so incredibly small as to be practically impossible.

Indeed the addresses do not have a public key associated with them at the moment or indeed for the foreseeable future.

Most addresses cannot be mistyped into other valid addresses with just the change of one character or one transposition.
I estimate that there's about a 0.1% chance that a given address can be converted into another valid address by substituting just two of the characters, so it's not too much of a risk.

However, given that the checksum ensures that the addresses are 5 or 6 characters longer than an unprotected address, the guarantees that they provide are far from optimal.  It would be better to employ an error correcting code designed to detect and correct substitutions, insertions, deletions and adjacent character transpositions. It's reasonable to imagine that equally protected addresses using the new scheme might be two characters shorter.

It would be an interesting problem to determine which of the bitcoin addresses with known public keys or holding a significant balance are most vulnerable to being mistyped.

ByteCoin

[tschaboo]

It would be better to employ an error correcting code designed to detect and correct substitutions, insertions, deletions and adjacent character transpositions. It's reasonable to imagine that equally protected addresses using the new scheme might be two characters shorter.

That's a very nice idea. Although I would not aim for a correcting but just a detecting code. As long as the code is shorter than the address itself there is always a chance that the correction is wrong. And you don't want your client to correct to a wrong address. Never ever. But reducing the risk of a mistype being accepted by the client would be very welcome.