Adding support for whitelisting

While in contrast with the permission-less ethos that inspired the RGB project, looks like security token issuance often chose to implement whitelisting procedures to create a defined set of user that are allowed to own the token. This is usually done to be compliant with applicable regulation of the jurisdiction of the issuer, and while it is fair to argue that if you want to do whitelisting you could as well just use a centralised database instead of a permission-less protocol, still there is market demand for this feature today and other use cases may require it in the future.

One option to support this could be to add a "whitelist" field in the contract so that the issuer can define a set of public keys that are allowed to own the asset, and each future payee will validate that all the whole transaction graph only include whitelisted public keys. However this would have two problems: first it is not extensible, so after issuance it wouldn't be possible to add new keys to the list, and second it is not ideal privacy-wise as everyone would be able to see the full list of whitelisted keys.

A better alternative would be to declare in the contract an authorising (list of) key(s) that can sign messages in the future that authorise users' keys. In this way the payer will have to provide to the payee a proof-of-whitelisting by showing the message signed by an authorising key defined in the contract, and this proof will be passed on and validated along the client-side transaction history. In this way the issuer (or a delegated party) can keep adding keys to the list, and each user will only know about the set of whitelisted keys that are necessary for the validation, not the complete list.

Some use cases may also require blacklisting logic, but that would be dangerous to implement as while validating that a key has been whitelisting is easy, doing the opposite which is validating that a keys are not part of whitelisted is impossible in a client-side validated system without a global state visible to anyone. Therefore blacklisting could at most be implemented as complete list of keys defined in the contract, but it could not be changed after issuance, making it not very useful.

While this feature can be useful for some applications, it is probably not a priority and can be reserved for a future version of RGB.

LNP-BP / LNPBPs

Adding support for whitelisting #73