Deposit offer whitelisting

[knikos]

Why this should be merged

This PR addresses the need of maintaining (storing/retrieving) signatures used for enabling certain addresses (whitelisting) to deposit funds on certain deposit offers.

How this works

The solution consists of 2 new api methods (AddSignature and GetSignatures), a new db table for storing the signatures as well as the service logic that facilitates the storing and retrieving the information.

API changes

The new deposit offer service consists of two new methods:

• AddSignatures (POST): requires the fields deposit_offer_id, addresses and signatures. An optional field timestamp can be provided to determine the time period to search for active deposit offers. If none provided, current server timestamp is used.
• GetSignatures (GET): requires the address for which signatures should be retrieved. Furthermore, a timestamp alongside with a signature are required to ensure restriction of access. Finally, a boolean flag called multisig is used to determine whether the provided address is a multisig alias or a signlesig address.

DB changes

The new db table stores three fields: deposit_offer_id, address and signature. An index is also created for the whitelisted address as signatures are expected to be queried based on that address.

Notes:

• Adding signatures is also restricted only for valid deposit offer owners to prevent flooding the db with meaningless data.
• Accessing the respective signatures is restricted only for whitelisted addresses or members of whitelisted msig aliases. Each alias member can access individually the signature associated with an alias.
• Multisig: applies to whitelisting and not to ownership. When whitelisting an msig alias, the owner just needs to provide 1 signature as he'll whitelist the alias itself and not every participant.

How this was tested

Manual and unit tests