implement basic send & receive pages

[ghost]

just a single ordinary single send with value. we need sanitisers anyway so make the sanitiser for floating point values as well as in this case the maximum spend.

[l0k18]

and the receive page don't forget

[l0k18]

receive page is now done

[l0k18]

starting on send page, basic spec is a simple single send transaction and a simple addressbook with labels for addresses, that is populated by the form (send and save button, save the amount doesn't matter)

[l0k18]

Some notes about the implementation:

Neither send nor receive addressbooks can have entries added without message/label annotations. These are just clutter. So unless a receive has both fields filled, it won't store a new entry or update the QR code this way, nor store a send address.

To enforce this, the regenerate button should be inactive if either field contains nothing. The user will grasp intuitively that the QR code is not a new address if they haven't been able to press the regenerate button.

Similarly, the send button will remain inactive until there is both an amount and a label/message. This is simpler than indicating error fields anyway, and the user will not have to guess many times to figure out this is why the button doesn't activate, only one character has to be in both fields and it will light.

Now, there is a security and UX side to this - sometimes scammers may trick someone into sending a payment. By forcing the user to make a note about it, they at least will be able to see by the record (it will show up on tx view when that is implemented also) what this payment was "for", and in the case of being scammed, the note will help the user recognise what has happened, so they can warn others about this incident and provide a meaningful story about it, assisted by their having to make a note what it is.

Further, it is bad accounting practice anyhow to leave a payment without annotation, as good money management requires occasional audits of the records and missing annotations are next to useless, since, while the address is a useful data point, it is not going to remind the user at all what the payment was about, and if no other record can be found bearing the address, the user has to scratch their head about what the payment was for. The lazy user who doesn't care can just put one character in the field, but they have at least been forced to make any note, which might prompt them to question their lazy accounting practices.

[l0k18]

Basic functionality is now done, what remains is proper feedback and a password prompt.

The handling of the wallet password has to be changed, I think that it won't write a new value to the field and pulls the one saved, which is the hash of the password for pre-api-call validation, which is stored when the wallet is created.

the walletpass field needs to be cleared after wallet unlock, and the simplest way to implement the password input is to put it directly in the form, as must be entered and by this, the user knows they have to enter it to press the send button.

Ah yes, and the password field can even do this as well, since the hash of the wallet password is stored in the pod.json file, it can be instantly compared and if it is correct, the send button activates.

A remaining issue is that the wallet does not encrypt transaction records. Possibly this can be resolved by adding a flag that indicates the wallet does not store these (as they are in state.json, anyway, and can be derived from the chain), and in addition, to avoid a total chain wallet address scan, the scans should always start from the next block height after the one stored in the state.

Hell, the whole wallet can basically be pretty much gutted, actually, set so it stores nothing except the seed and imported addresses, as the state variable stores everything else, encrypted as it should be. So, with the new GUI mode added, the wallet rescan is always 'manually' set to scan from the oldest un-scanned address, and the transactions are in state.json. This leaves the functionality as a pure server wallet intact for this type of use (such as for websites, but note that such server instances should be heavily protected from intrusion anyway) .

The existing design has very specific assumptions about use case that don't cover either of the cases for our purposes that well. In fact, for custodial services and the like, the wallet needs to have full account support, which it doesn't. So later on, such alternative formats for the wallet will be implemented for these purposes.

For now, it is most probable that exchanges already presume this single account implementation, as it is very common, and they manage tracking user accounts shares of the wallet balance in their exchange application back end. Putting an item in the project to make note to learn what exchanges expect and what their apps expect from the wallet RPC. Presumably my guess there is usually separate account balance tracking in the exchange application is correct since after all, Decred uses the same base and likely have not fixed the account handling, or encryption in dcrwallet, but these questions need to be authoritatively determined.

[l0k18]

have now got send recording txid in the transaction, next can retrieve txid and generate other view mode for card with tx details as per other tx details which are being done in the other issue concurrent with this one at the moment. For that, this requires a bit of a change to design as it needs two distinct buttons for this view where the tx info list detail view can be just one button to show details and only the tx view needs more buttons to copy tx details out

[l0k18]

this is pretty much done now