Quote from: pandaisftw on January 08, 2014, 07:05:46 PM

Quote from: bitcoinpaul on January 08, 2014, 01:02:13 PM

Quote from: Jean-Luc on January 08, 2014, 12:53:56 PM

Quote from: bitcoinpaul on January 08, 2014, 12:50:19 PM

We don't integrate some sort of CRC because of saving a tiny bit of memory in the core code and because sort-of-CRC could be done in a/the client, right?

No, because in the core and when sending across the network the transactions are already signed with the sender public key. Any corruption in the transaction content would automatically invalidate the signature.

Sounds reasonable. And what are the options for the client software for user-made input-errors?

Spontanious idea: The client software can handle "#account" and "#account"+"account alias" receiver-adresses. The second could be checked by the client before it is signed. It would be convenient and the user felt kinda save.

Mmhh, other ideas please?

This is actually a really good idea. For large movers, like an exchange, they can require the user to enter their account number and an alias from that account. That would get rid, of all doubt, that the exchange/user made an input error. If there is no memory corruption issue (the devs say that cannot reproduce this), then this system should be golden.

The only problem I can see is: if someone buys from an exchange from the first time and does not have an existing account, he can't transfer to any account he wants. A solution is to only apply this account+alias rule to medium-large deposits/withdrawals. So a new user could, say, send 1 NXT to his new, super secure account, register an alias, and then send the rest of his funds with account+alias from the exchange to his account.

As for the Account Control, I like the idea of being able to restrict outgoing transactions. I think these two options would be very flexible:

Maximum amount X per Y time-frame
Timeframe allowed to send funds

With just these two parameters, you can, for example, set X = 0 to completely lock outbound transactions. For everything else, it's more convenient to have a self-defined limit for day-to-day transactions. If one really needs to make a large purchase (uncommon), then they can simply unlock their account, then re-lock after.

More choices, I like Grin

We lock (locking method not clarified) not the account but all outgoing transactions which would exceed the cumulated outgoing nxt amount in a given time frame. So you can set this amount to whatever you want. (0 = complete 'lock of the account' for example)