Add back WhitelistedCrowdsale

[nventuro]

This creates a new WhitelistedCrowdsale, similar to the pre-2.0 one, but now using Roles.

The creator of the crowdsale is assigned the Whitelister role. This role can be added to other accounts, and cannot be removed (by default).

Whitelisters can also give the Whitelistee role to any acccount. Whitelistees can renounce their role, but cannot give it to other accounts, nor can they remove it from any account.

The crowdsale only processes token purchases where the recipient of the tokens has the Whitelistee role. Note that this doesn't prevent the token to then be transferred to non-Whitelistee accounts: such a restriction would have to be imposed at the token level.

As an experiment, I enhanced the PublicRole.behavior to support the concept of 'managed roles': how each role is tested differs slightly depending on whether the role is managed (Whitelistee) or not (all other roles). This may be extended down the line, as more differences between roles arise, but it suffices for now - I didn't want to go overboard with a full-fledged role configuration object.

Closes #1292

[mjdietzx]

Hey @nventuro, this looks great! The whitelist looks good and the crowdsale is a nice example of using it.

Note that this doesn't prevent the token to then be transferred to non-Whitelistee accounts: such a restriction would have to be imposed at the token level.

From what I've seen, the important thing with security tokens is that at any point in time, accounts holding these tokens can be identified. So I think most use-cases will need to do something like this at the token level as you suggest (performing this check in transfer and transferFrom).

[nventuro]

Thanks for reviewing @mjdietzx! One more tiny question, so as to not derail the discussion here: is it token holder identification that's needed, or restriction when transferring? Detection should be doable via events, with no modifications to the contract code.

[mjdietzx]

One more tiny question, so as to not derail the discussion here: is it token holder identification that's needed, or restriction when transferring?

At least in our case (regulated in Switzerland / Lichtenstein), we need to be able to identify any token holders. This means given a wallet address, we can tie this to a person's identity. So because we restrict transfers, we can guarantee that only 'known' addresses hold tokens, and therefore we guarantee we can identify them.

If transfers aren't restricted, a known address could purchase tokens during the crowdsale (all good so far), and later transfer them to an 'unknown' address (by any means, i.e. an exchange, p2p). And that would be a problem for us.

[levino]

I think there should be some documentation as a markdown file on the functionality of this crowdsale.

[nventuro]

@levino what sort of documentation would you like to see there?

[levino]

Hm.
token.addWhitelister('123'), token.addWhitelisted('123')
Spot the difference? I think it should be token.addWhitelistAdmin('123') instead of the latter. Too dangerous.

[levino]

@mjdietzx Did you manage to implement the following rule: When tokens are to be transferred, the sender and the recipient must have the role Whitelisted. I am only able to check the whitelist status of the sender (with the current implementation of Whitelisted).

[levino]

I added my own modifier to the contract code:

    // Token.sol
    ...
    modifier checkAccess(address account) {
        require(isWhitelisted(account), "only for whitelisted");
        _;
    }

    function transfer(address _to, uint256 _value)
        public
        checkAccess(_to)
        checkAccess(msg.sender)
        returns (bool)
    {
        return super.transfer(_to, _value);
    }
    function transferFrom(address _from, address _to, uint256 _value)
        public
        checkAccess(_to)
        checkAccess(_from)
        returns (bool)
    {
        return super.transferFrom(_from, _to, _value);
    }
    ...

[levino]

I also have another remark about the current design:

So the whitelisting will be automated, I suppose. Lets say we have some server side code that verifies some user input data and then adds an address as whitelisted. Now some attacker gets access to this server and uses the whitelister private key to add himself to the whitelist. Then they could remove all other whitelisters and as such take over the smart contract, right? It would be nice to have an additional Owner who can reset the whitelister-list.

[levino]

Okay, I see now that noone can remove whitelisters. But still the attacker could do a lot of trouble.