Better feedback when unprintable characters in Bitcoin address

[sgornick]

There are some problems with people copying and pasting an address where the address includes an unprintable character.

For example, some web apps will inject an #8203; into a long word so that a line-break / word wrap will occur. But the user doing a copy and paste won't see this character.

• http://stackoverflow.com/questions/2973698/whats-html-character-code-8203

When trying to paste this into the PayTo: field of v0.6.2, the paste does not succeed. There is no feedback given as to why this paste does not occur.

In previous versions (perhaps v0.5.x/) apparently the paste will success but the validation fails on send (highlights the field in red). Still though there is no further feedback as to what the problem is.

The user then feels the problem is with Bitcoin-Qt as that same copy and paste on an EWallet (e.g., on Mt. Gox website) works fine (presumably because they strip out nonprintable characters from an address?)

Here's an example of users reporting this issue:

• http://bitcointalk.org/index.php?topic=82004.0

Here's what the "view source" for the web page shows:
1G5apmPvo2iTtmkNWAHTCET7​Y842Ufijs8

[laanwj]

Sneaky. But I think this would be pretty simple to solve; in the correction phase of BitcoinAddressValidator::validate, delete these characters from the string.

[gmaxwell]

I don't generally like the idea of the validator "fixing" broken addresses, because it's perfectly possible for one character variations to also be valid. ... but the case of random entities stuffed in, that seems pretty safe to fix to me. Perhaps we should decode any entities, then strip only whitespace/linebreaks?

[laanwj]

I don't like the idea of decoding entities at all.

From what I understood it is not about entities stuffed in, but actual unicode characters. Those show up in html source as entities, but appear as normal utf-8 characters when copy/pasted into a plain text field. Those QChar(8203) are easy and safe to filter out, along with other whitespace/linebreaks.

[gmaxwell]

Okay, to be clear— I think stripping whitespace is okay. I don't think stripping or replacing other characters is okay. To the extent that whitespace might come in the form of entities I'd be okay with stripping that to. I didn't mean to advocate decoding entities if not needed.

[laanwj]

We already replace other characters: l and I are replaced by 1, 0 and O by o. This is just a convenience for the user and does not give any confusion in base58.

Edit: but I agree that, beyond that, we should not try to 'fix' the addresses.
Edit.2: I also think you mean another validator, this is the one used for input fields in bitcoin-qt, not the internal validator used in the core. The user is able to visually inspect the result before submitting.

[laanwj]

See #1329

[gmaxwell]

I must have missed that change going in, as I specifically remembered NAKing #552 . I continue to think that the character substitution is a bad idea (in a way that whitespace removal isn't).

[laanwj]

It was already in there from the beginning of bitcoin-qt. I think it is harmless, at most. Users typing in base58 addresses from paper, for example, should not have to care if something is a 0, o or O as they look visually the same and AFAIK that was the intended idea of base58.

[laanwj]

Fixed