Re: CRL for the node Identities

Mike Hearn
 

So whereby in the legacy financial world, the FBI are able to seize assets of wanted criminals or organisations, the argument that they cannot do the same on-ledger in order to retain the key tenets of decentralisation is unlikely to wash, at least in the short term.
Absolutely agree, and thanks for the list of benefits retained even with ability to freeze coins. Although seizure of blockchain assets can always be implemented by seizing the private keys themselves, as done in the Bitcoin world, you might be right about needing to be able to do it yourself depending on local laws.

To implement a general bank-style seizure-of-funds framework, there are a few ways to do it without certificate revocation being involved that trade off various factors.

You could make yourselves participants in every state, enforced using verify logic that looks for a hard-coded public key. Then every transaction would be sent to you, and you can thus monitor the flow of funds everywhere. To seize it you can just implement a command in your smart contract called Seize that again looks for your hard-coded public key and then allows the ownership of the tokens to be set to something new. So you are effectively a co-owner of every token.

This works up until SGX is deployed. Then the adversary may simply not report their transactions to you, and the later downloads of resolved dependency transactions would be considered private data of whoever next choses to report a token movement to you. There could potentially be a backdoor in the enclave of some sort, but it'd also require disabling confidential-identities and other privacy features. I'm not sure how to provide privacy in a world where everyone feels a need to know the history of everything in case they've been through 'dirty hands' (because I doubt this power would be requested only by token issuers).

You could make yourself a participant and require a signature from you over every transaction that moves tokens. That solves the above issues, but then an outage at your company freezes trading with those tokens, potentially opening up major SLA risks with concomitant financial risks. Additionally that'd make you closer to a normal bank/payment processor rather than something more like a cryptocurrency exchange or stored value issuer (EU e-cash rules), so you'd become responsible for the legitimacy of every payment.

Neither approach is ideal - there are inherent tensions between reliability, performance, privacy, globalisation and traceability/seizability. How national sovereignty interacts with internationally traded tokens is also problematic.

But anyway, you can implement either for now, PKIX revocation isn't needed.

A long time ago I decided I didn't have enough enemies in the world so wrote down a proposal for Bitcoin "red listing", which was meant to be a cross between coin blacklisting (merchants aren't allowed to spend or touch certain addresses once blacklisted i.e. similar to revocation as discussed in this thread), and whitelisting (merchants refuse to accept coins unless you can know everyone it's passed through - too aggressive w.r.t. what the law actually requires). Instead various authorities interested in tracking down abuse would publish StateRefs on a public list and anyone who encountered coins that traced back to those marked coins would contact the authority, telling them where the coins came from. Having alerted the authorities they'd either (a) get to keep the coins, if they weren't stolen or (b) have to give them up if they were being reunited with their rightful owner, or seized for other reasons. If they didn't report, then the next place they used the coins would report them and the authorities could work backwards through the chain of custody, getting each link in the chain to reveal who comes next.

It avoids servers becoming single points of failure, tracing across national boundaries is handled via the usual MLAT treaty agreements abuse can be tackled without centralising all authority in anyone's hands (which most countries don't normally do - the USA's approach with OFAC is unusual). Most usefully when ID verification fails there's contextual information that can be used to help, e.g. the re-entry into the white economy might tell you a lot about the true identity of the prior token holders, in case they were able to beat KYC procedures (quite common). It could be implemented inside SGX too.

This approach is interesting because everyone hates it, which might imply it's a meaningful compromise :) It was also interesting because it's compatible with today's laws, given that in cryptocurrencies the only regulated entities are exchanges and payment processors. Normal merchants don't fall under AML regulations (outside of special cases like estate agents and casinos). However that approach didn't envision attempts to be both a bank and a decentralised token simultaneously via issuance of proxy tokens - that's been explored a bit for consumer use cases in the EU e-cash regulations, but for industrial use it's new territory and the regs as written aren't a good fit. To get the best out of the technology, token issuers may need to work with regulators to show them how a good balance between innovation, resiliency and crime fighting can be found (kinda like how Patrick Murck did so in the first years of Bitcoin).

Conclusion: negotiation with governments aside, it feels like this set of needs can be met with the standard smart contract framework and PKIX CRL/OCSP support isn't needed.

Join corda-dev@groups.io to automatically receive all group messages.