Quote from: nexern on January 03, 2014, 07:46:02 PM

Quote from: ZeroTheGreat on January 03, 2014, 07:33:06 PM

Quote from: nexern on January 03, 2014, 07:26:09 PM

already wrote about this two weeks ago.
the client wil handle it this way:

1. check if address is within own address book -> green
2. if account exist within blockchain -> yellow
3. don't exist within blockchain -> red

simple visual control.

Thx. But what about after clicking "Send"? As I recall wrong sends happened after correct address was set.

you mean some kind of checksum?
as soon there is a difinition for this i am adding it for sure.
the above mentioned solution is of course very simple but effective as well.
within an option tab you can set the warning level. of course the user will get
an extra confirmation dialog for yellow and red after pressing send.

a realtime verification during typing depends on the gui-latency but as soon the
account number field lost focus the number is checked and gives a visual feedback.

intel, the person with handle not company, had a theory that memory corruption in the JAVA could cause the destination acct to get corrupted. Another theory is that it could be a race condition of some sort that exposes an uninitialized variable, basically stuff that is outside the realm of what the client can do.

WE need to refuse to create darkNXT in the client and independently refuse to create it in the JAVA and ideally refuse to create it in the protocol. What purpose does darkNXT serve other than to piss people off because they lost small to large amounts of money. In alpha test, ok. In beta test, maybe ok but not really. After formal launch we can never create darkNXT, unless we are willing to reimburse, which does not seem likely.

Ripple does this better than NXT. Can we really allow that to stand?

Nexern, there is only so much you can do in the client.

James

P.S. Sorry CfB, we might even need a "allow darkNXT creation" API call. That is how difficult it needs to be. No laughing matter extinguishing peoples money.