Re: CRL for the node Identities

Mike Hearn

If you're using reference states like that, the check is done only when the tx is notarised. So if Bank A has their tokens frozen after the tokens were sent to bank B, the freeze would have no effect.

I guess in reality you'd want the ability to seize rather than freeze funds, and do it in a partial way because the actual target wouldn't be an entire bank but rather, just some individual users.

For the record the above design pattern should hopefully allow for mitigating the loss of an account's Private Key: IE - KYC may be revoked as a way of freezing the funds and we are free to just re-issue their Tokens to their new private key.

If the identity key is lost they'd need a new legal entity under the current rules, as that one would be toast. But if a central counterparty can reissue states at any point unilaterally then yes, that works. It's equivalent to erasing the vault and starting again.

I can see the following questions with generalising this approach:

  1. If the issuer can just seize funds at will, then is it really a decentralised system? What are the benefits being obtained by using decentralised tokens, if there's a party with that sort of power?
  2. How does it work for non-token apps, if at all? It implies states would have to be creatable in any state at all regardless of prior evolution, but then that implies the smart contract logic is useless - you can never reason about how a state evolved over time because it could have just been created out of thin air. And again if the app is written that way, are you still preserving the aspects that led to the use of decentralised systems in the first place? Someone has to lose the power to fix mistakes at some point.
  3. If I can route my tokens through another party that doesn't get revoked e.g. deposit my tokens at an exchange and then immediately withdraw such that my tokens got swapped, propagating freezes would achieve nothing as it can't really propagate through the dependency graph like that: you'd end up halting trading at the exchange.
It's probably worth clarifying what use cases you're aiming to solve:

  • Is it key compromise in which case reissuance to a new key might make sense?
    • Or does it make more sense to track down where the tokens went, to avoid the problem of issuing duplicate claims on your underlying tokenized assets?
  • Is it sanctions enforcement in which case you don't want to reissue, you want to seize the assets and change the owner (or delete, if the government is seizing the underlying assets)?
    • But in that case how do you identify the set of tokens you wish to seize, and ensure that propagates through spend-to-self splits and merges?

Join to automatically receive all group messages.