Quote from: Come-from-Beyond on January 08, 2014, 04:18:08 PM

Quote from: NxtChg.com on January 08, 2014, 04:16:37 PM

Quote from: wesleyh on January 08, 2014, 04:02:57 PM

Will make some sort of popover that shows where it links to (in browser extensions)

Blacklist of malicious aliases might be a good idea too...

Who will decide if an alias is malicious enough?

Could be through a 3rd-party web of trust type plugin, or blacklists maintained by 3rd parties. Most important I think is that the user retain the choice of how they want to filter malicious aliases (if at all). So ultimately users, and user demand decides.

Quote from: Come-from-Beyond on January 08, 2014, 09:44:33 PM

Quote from: NxtChg.com on January 08, 2014, 09:27:20 PM

Would you kindly pull your collective head out of your collective ass and start taking this issue seriously?

Well, give me an answer on a simple question:

- Where CRC should be added to protect a user from sending 90000 NXT instead of 80000 NXT and how is it different from incorrect account issue?

The solution to that does not have to be through CRC, or other checksums. For instance, to prevent miscommunication for short spoken strings, militaries pad out letters and digits. For instance, they may say NINER instead of NINE. If the problem is the number of digits, e.g. if folks worry about sending 800000 instead of 80000, commas can be used. Easier to spot the difference between 800,000 and 80,000. Different solutions for different problems.

I personally worry about these sort of inputs and double and triple check. As a newcomer to crypto$, all this worrying and checking stressed me out the night I made the trade offer in this thread. So it is a problem for me; I would much rather feel safer with more safeguards built into the protocol/client. For the amount to send, having to type it in two separate fields and disallow pasting in one of them (like email address confirmations) could be a way of solving the problem, and relieving user anxiety.

But I worried about the accuracy of addresses much, much more. NXT addresses are not easily eyeballed like transaction amounts or aliases.

A while back, when I asked CfB about using some of the 192 reserved address bits for check bits, he replied "We can't", which I took to mean it was impossible (without messing up a lot of things). I have much less coding experience and knowledge than most folks here, so on things like the current protocol I trust and defer to others. Now I'm reading stuff that suggests it might be possible. But whether client or protocol side, something MUST be done about this.

One of NxtChg.com's concerns is that if checksums are not implemented at the protocol level, it will not gain widespread adoption. I'm not so sure about this; seems like if no better solutions emerge, this could be adopted as a best practice when designing clients. I'm sure client designers also worry about address accuracy and don't want donations to get sent to the wrong places Grin

And after a while, maybe standard libraries/code fragments would get reused, so clients (and consequently users) would converge to standard ways of guarding against errors. He's got some server-side concerns too, which I don't have the experience to say anything about.

Breaking up NXT addresses into groups of digits (like credit cards) might help a little.