This may have been suggested before, but I would like to propose that all bitcoin addresses should be displayed with a 'standard' checksum associated with it. Why? Because I think it is far too easy to make a transcription error, for example, take the following address:

31uEbMgunupShBVTewXjtqbBv5MndwfXhb

And compare it with this one:

31uEbMguoupShBVTewXjtqbBv5MndwfXhb

You could be forgiven for not noticing they are not the same. But, if we used a 'Standard Check Number' (in this case CRC32) that is displayed with the address then the difference is obvious.

Address: 31uEbMgunupShBVTewXjtqbBv5MndwfXhbCheck: FF4857EB

Address: 31uEbMguoupShBVTewXjtqbBv5MndwfXhbCheck: 1855F17C

Of course it doesn't have to use CRC32, but in order for it to work a standard for 'Check Numbers' would have to be decided upon. They can then be compared across all bitcoin software and services and reduce the chances of payments being sent to the wrong addresse.

Thoughts?

(Mod note: not sure if this is the correct section to post this in please move if not)

This may have been suggested before, but I would like to propose that all bitcoin addresses should be displayed with a 'standard' checksum associated with it. Why? Because I think it is far too easy to make a transcription error, for example, take the following address:

31uEbMgunupShBVTewXjtqbBv5MndwfXhb

And compare it with this one:

31uEbMguoupShBVTewXjtqbBv5MndwfXhb

You could be forgiven for not noticing they are not the same. But, if we used a 'Standard Check Number' (in this case CRC32) that is displayed with the address then the difference is obvious.

Address: 31uEbMgunupShBVTewXjtqbBv5MndwfXhbCheck: FF4857EB

Address: 31uEbMguoupShBVTewXjtqbBv5MndwfXhbCheck: 1855F17C

Of course it doesn't have to use CRC32, but in order for it to work a standard for 'Check Numbers' would have to be decided upon. They can then be compared across all bitcoin software and services and reduce the chances of payments being sent to the wrong addresse.

Thoughts?

(Mod note: not sure if this is the correct section to post this in please move if not)

Except that bitcoin addresses have a 'standard' checksum built in to them, so a transcription error will almost certainly result in an invalid address that the client and network won't accept. Every case I've seen so far of someone reporting that they sent to the "wrong addressee" was due to them pasting/entering a valid address that they got elsewhere and not from a transcription error.

The last 4 bytes of every address are the first 4 bytes of a double SHA256 hash of the rest of the address.

Yes, the address has a checksum built in, but not one designed to catch transcription errors. There's a 1-in-232 chance that a random typo will still create a "valid" address. Using a checksum scheme that is guaranteed to catch common somebody-typing-an-address-from-paper mistakes (like transposing characters, hitting a nearby key on common keyboards, or entering in a letter with the wrong case) may make sense for some applications. I don't think CRC32 is the best choice, since it's designed for wire transmission errors, not for human typo errors. I don't know if a standard of just showing the checksum next to the address is the best approach, or if we want to invent a new address version, but it'd be nice to do something.

Though if we move to a future where all addresses are encoded via QR codes or sent through a payment protocol, so humans never see addresses anymore, it might not be worth the effort of doing.

Yes, the address has a checksum built in, but not one designed to catch transcription errors. There's a 1-in-232 chance that a random typo will still create a "valid" address. Using a checksum scheme that is guaranteed to catch common somebody-typing-an-address-from-paper mistakes

No an additional checksum won't "guarantee" anything. It will still have some probability based on the size of the checksum and the algorithm used to fail (especially with double transposed errors). Worse if it requires optional or manual verification the chances of it catching anything significantly decrease. The built in checksum provides 99.9999999767% probability that a typo will not produce a valid address.

My guess it the OP is unaware that all Bitcoin addresses have a built in checksum. Honestly I have never heard of anyone losing funds to a typo. Not once. Ever. Plenty of reports of hacked accounts, corrupt wallet files, malware attacks, stupid mistakes (formatting computer and no backup of wallet.dat), and the occasional "oh shit I sent wrong amount" or "I sent funds to wrong (but valid) address".

Yes, the address has a checksum built in, but not one designed to catch transcription errors. There's a 1-in-232 chance that a random typo will still create a "valid" address.

I'm not sure how CRC32 works, but wouldn't CRC32 also have a 1-in 232 chance that a random typo will create the recognized/displayed checksum? If so, it sounds like you are just arguing for using more bits from teh SHA256 hash that is currently used as a checksum. Perhaps it would be satisfactory to you to use the first 8 bytes instead of the first 4 (creating a 64 bit checksum)? Personally I'm ok with 32 bits. The odds that I'll make a typo are slim to start with. Multiply the odds that I make a typo by the odds that the typo will generate a valid checksum and it quickly becomes something that isn't of concern to me.

. . . Using a checksum scheme that is guaranteed to catch common somebody-typing-an-address-from-paper mistakes . . .

Define "guaranteed". No matter what method you use, there will always be some sort of chance that the address entered (verification method chosen) will match on an incorrectly entered address. If 32 bits isn't enough, do we need 128? 256?

If you tried to send fund to this address by mistake the transaction would fail because it is not a valid address1Gt4PGm6HNBSMvQh3fTNfDSxE9tW26XXNv

The probability of mistyping and still producing a valid address is roughly one in 4 billion. If you mistype 1 million addresses in your lifetime there is still a 99.97% chance that none of the typos in your lifetime will produce a wrong but valid address.

I often double/triple check addresses and I think what I'm asking for is just to give me piece of mind. I feel especially uneasy when sending an address via IRC, I think it would be nice to be able to do the following;

IRC Chatlog:

Me: Here's my address 31uEbMgunupShBVTewXjtqbBv5MndwfXhb

Other: check FF4857EB

Me: confirmed

This would give me confidence that the address that was enter into the wallet by the other person is indeed the address I wanted to send to them.

. . . Using a checksum scheme that is guaranteed to catch common somebody-typing-an-address-from-paper mistakes . . .

Define "guaranteed". No matter what method you use, there will always be some sort of chance that the address entered (verification method chosen) will match on an incorrectly entered address. If 32 bits isn't enough, do we need 128? 256?

Sorry I wasn't clear. I meant "guaranteed to fail validation if only one common problem exists" for the common problems of character-with-wrong-case, transposition, etc. I don't know if it takes more than 32 bits to ensure all that, but I thought that there exist checksums designed for human input problems rather than random bit errors, and I was trying (and not very clearly) to suggest that if we want to change or improve the address checksum, we should use one of those. I'd agree that it's not clear that a better checksum is needed, especially with the work on a payment protocol and with more and more usage of QR codes which use their own checksum.

If what you're looking for is that the address is actually from the person that you think it is from (particularly if it's coming through an insecure messaging system), than what you're looking for is for them to GPG-sign-and-encrypt the address first, and/or use the snazzy payment protocol that the devs are working on.

If what you're looking for is that the address is actually from the person that you think it is from (particularly if it's coming through an insecure messaging system), than what you're looking for is for them to GPG-sign-and-encrypt the address first, and/or use the snazzy payment protocol that the devs are working on.

No, what I'm looking for is a quick and simple way of checking that two addresses are indeed the same, without having to make a detailed comparison of all the characters in the two addresses.

If what you're looking for is that the address is actually from the person that you think it is from (particularly if it's coming through an insecure messaging system), than what you're looking for is for them to GPG-sign-and-encrypt the address first, and/or use the snazzy payment protocol that the devs are working on.

It sounds to me like what he's looking for is more of a way to ensure that the address is correct (no typo) when given to someone else (not when used to send the bitcoin).

Imagine this scenario:

You and I are both online at the same time right now. You agree to send me some bitcoins later today (for some reason you don't have the bitcoins available right now). I send you a bitcoin address, but make a typo as I enter it (for some reason I choose not to cut&paste). We both go offline.

Later in the day (when you finally have access to your bitcoins) you attempt to send me what we agreed to but discover that the address I gave you is invalid. Unfortunately you are leaving on a trip that evening and won't be back online for a month.

I get upset that I haven't received my bitcoins and declare you a scammer ruining your reputation. When you get back you explain the situation and we resolve it, but not before a whole lot of anxiety, frustration, anger, etc. All of which could have been avoided if just there was an easy way for you to confirm right away that the address I gave you was valid when I gave it to you.

How likely is a scenario like this? I don't know.Why couldn't the sender attempt the send (and therefore discover the invalid address) while we were both online? I don't know.Why couldn't I use cut&paste to ensure there were no typos when I gave you the address? I don't know

But if the presented scenario (or anything else where quick and easy confirmation of an address would be useful) is likely at all, then I suppose I could see some use in having a checksum that is not sent with the address visible in the client. That way when you received the address, you could generate the checksum locally and send that result back to me. I could confirm that the checksum you send me matches what I see in my client and therefore know that you don't have a messed up address.

Am I the only one who makes comparisons between bitcoin addresses? Or do other people just paste & send without giving it a second look?

What are you comparing it to? You do understand there is a CHECKSUM BUILT IN? Take an address you own and leave off a letter, change the case of a letter, add a letter, replace a letter, etc and try to send a bitcent to it. The client won't let you. Keep trying. Try a dozen, try a thousand. The addresses will all be invalid. Even with a million attempts, the odds are <0.001% you will be able to randomly make an address which is valid. If you want piece of mind try it right now. Try to send bitcoins to a modified address (send a token amount like 0.01).

The odds that you could mistype or copy an address and it still end up being valid but wrong is less than 1 in 4 billion.

Am I the only one who makes comparisons between bitcoin addresses? Or do other people just paste & send without giving it a second look?

What are you comparing it to? You do understand there is a CHECKSUM BUILT IN. Take an address you own and leave off a letter, change the case of a letter, add a letter, replace a letter, etc and try to send a bitcent to it. The client won't let you. The address will be invalid. The odds that you could mistype or copy an address and it still end up being valid but wrong is less than 1 in 4 billion.

. . . They can then be compared across all bitcoin software and services and reduce the chances of payments being sent to the wrong addressee . . .

If this is your concern, I'd hope that by now you'd see that with the built in checksum, you really don't have to worry about a typo resulting in payments being sent to the wrong addressee.

On the other hand, if you are worried about giving out an address that is no good (can't be used because it is invalid), then I suppose I can imagine a few extremely unlikely situations where having the client/wallet display a separate checksum might be useful. (See my post here)

Unless you can give me a real world example of a situation you encountered where other methods wouldn't have been just as easy, I'm not sure that I'm convinced it is something that is worthwhile.

Am I really the only one who makes detailed comparisons between bitcoin addresses to ensure they are the same?

I guess I must just be paranoid, maybe it's the irreversibility of a bitcoin transaction that scares me.

If this is true then you aren't going to be satisfied with the checksum you are requesting. There is already a 32-bit checksum built in to the address. If knowing that you still feel a need to make a detailed comparison between bitcoin addresses, then how is an additional 32-bit checksum going to keep you from feeling like you still need to make a detailed comparison between bitcoin addresses to ensure they are the same?