* 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
