d737242bb5
* Device is an unlogged user that is just able to scan incoming transactions * There's always a Device defined either we load one from indexedDB or create one * Logged users have a defined SPENDING_CLIENT that can sign transactions * The pairing phase is when a new Device is created, we need another Device to send it it's own spending key via normal 4nk messaging * The new Device then encrypt it and send it back * In another transaction, the first Device does the exact same thing (probably possible to optimize) * The logging phase is sending a 4nk message with the encrypted spending key and getting the clear key back, basically logging with one device of a pair is the same operation than pairing but in reverse * Revokation output is an unique output for both devices, the validity of the pair depends of it being unspent * Revokation output is locked with some random key that both devices will need to keep * Todo: 1. implement the revokation scheme 2. optimize the pairing/logging flow