MIT ChainAnchor - Bribing Miners to Regulate Bitcoin

Based on the information I have available to me, it appears that the MIT ChainAnchor Project is in part an attempt to get Bitcoin users to register their real world identities and associate their transactions with those identities. Initially this would be on an opt-in basis, however it appears that ChainAnchor has a longer-term plan to bribe and coerce miners into only mining transactions from registered users, eventually prohibiting non-registered users entirely.

If ChainAnchor is fully successful to use Bitcoin at all you would be required to first register your real world identity. Your transactions would be linked to that identity in a way that that a court order, or even a hacker, could uncover full details on every Bitcoin transaction you make - your entire financial history, and for that matter, the full financial history of all Bitcoin users.

This would be done in three main stages:

1. Create an opt-in registration system that allows participating users to register their wallet addresses (pubkeys) with their real-world identity, forming a “permission group”. Registered users can prove a given pubkey belongs to a given group pseudo-anonymously using a group signature. However there exists a backdoor that allows the system administrators to collude to deanonymize users.

2. Once a reasonable number of users have signed on, bribe miners to only mine blocks containing non-anonymous transactions from registered users, thus increasing cost and confirmation times for non-registered users. As part of the bribe, miners would also be required to register their identities.

3. Finally eliminate the remaining non-registered miners, making it impossible to use or mine Bitcoin without first registering your identity.

In short, ChainAnchor appears to be attempting to make the existing permissionless Bitcoin block-chain into a centrally controlled, permissioned chain.

My Sources

ChainAnchor isn’t public yet, other than a small blurb on the MIT Trust Consortium website. I’ve obtained leaked copies of their preliminary paper and overview slides from multiple sources (most recently from MIT themselves). I’ve also been contacted by people who alleged that they was approached by the ChainAnchor group for monetary and strategic partnership assistance. These people have given me further (alleged) details on the longer-term goals of the project in the context of Bitcoin. They also alleged that prominent members of the Bitcoin community are involved in the project, beyond the names listed on the paper and slides (Thomas Hardjono and Alex Pentland from MIT, and Ned Smith from Intel).

Unfortunately I haven’t been able to get anyone willing to go on the record and simply say who those Bitcoin community members are publicly; I don’t have transferable proof like phone recordings or videotapes of the alleged meetings. Given the potential consequences - e.g. breaking NDA’s with large companies like Intel - I can’t blame them for being reluctant to go public. But it does mean I won’t be “naming names” - I’m just not willing to accuse people of serious wrong-doing without iron-clad, fully public evidence.

That said, while not as dramatic as a public tar-and-feather session, I think a perfectly good outcome would be if the Bitcoin community members involved in this plan give up now that they know their plans are being leaked by people with a sense of ethics.

Other than being approached by Intel last year to work as a consultant, I personally have no business relationships or NDA agreements with anyone involved in ChainAnchor. I don’t know if the people at Intel who approached me are involved in this, but in any case I had to turn them down prior to signing any agreements as I was unable to legally do the on-site work they wanted me to do (I’m a Canadian citizen).

Registering Your Identity - Permission Groups

A group signature allows anyone in a large group of keys to prove their membership in the group, without revealing exactly which key created the signature. ChainAnchor reuses Intel’s EPID group signature scheme - widely used in Digital Restrictions Management (DRM) tech - to create “Permission Groups” of keys representing some kind of permission or attribute, such as the fact that the key holder has complied with AML regulations and registered their real-world identity.

Membership in a permission group is controlled by a group manager, which ChainAnchor refers to as the permissions verifier (“IdP-PV” for short). They have the sole ability to add new members, as well as the ability to revoke membership, with or without the co-operation of the member in question.

However the permission verifier is not supposed to ever know users’ real-world identities; identity registration is a separate role known as the identity provider (“IdP-PI”). In fact, ChainAnchor repeatedly warns that the two roles must be kept separate:

Similar to EPID and related schemes, the Permissions Verifier is assumed not to be in collusion with the Permissions Issuer, and both are expected to be a separate entities (physically, operationally and legally).

Why? The problem is that the underlying math used by EPID has a backdoor: the permissions verifier can use their private key to determine who actually made a given group signature. This means that the privacy of the system is based on trust: the permissions verifier and identity provider can undetectable deanonymize a user by colluding to combine the real-world identity and cryptographic identity information that each side is supposed to keep secret from the other. This means that warrants requesting information on user transactions can be met. It also means that hackers who successfully hack into both servers can potentially deanonymize users’ transactions.

Mining Permissioned Blocks

For deployment on Bitcoin, ChainAnchor proposes a scheme where miners opt-in to mining “permissioned blocks” containing only compliant transactions from registered users that spend money from, and send funds to, addresses in a permission group:

The technical details of how this works is straightforward: for every transaction a compliant miner receives, check all addresses with the permission verifier to ensure they’re in the permission group whitelist. If not, discard the transaction.

Why would a miner do that, potentially losing out on fees from non-compliant transactions sent by unregistered users? ChainAnchor suggests bribing them:

In the ChainAnchor semi-permissioned overlay a successful miner receives a further additional payment (beyond the new coins and transaction-fees in Bitcoin) for completing a block consisting only of permissioned-transactions.

Of course, to receive your bribe, ChainAnchor expects the miners themselves to be compliant, with a verified identity on hand:

For a validated permissioned-block, IdP-PI and IdP-PV must verify that the successful Miner’s public-key is found in the Verified Identities Database. That is, they both must ensure that the Miner has executed the zero knowledge proof protocol with the IdP-PV prior to mining for ChainAnchor permissioned-transactions.

Why? Obviously we can’t go around paying bribes to miners unless we know their real-world identities:

This last step is needed in order for the Miner to be remunerated by the Owner of the permissioned-group through the IdP-PI.

It’s striking how absolutely none of the above has anything to do with technology. If all ChainAnchor wanted to do was create an opt-in AML-compliant address whitelist, why would they care if miners create blocks that also contain non-compliant transactions? Given the system is reliant on always online permission verification servers anyway, the obvious thing to do is just keep track of what transaction outputs are compliant in a database - exactly what services like Chainalysis do anyway.

It’s all just ones and zeros - do the ones and zeros of non-compliant transactions have cooties?

What’s likely going on here is ChainAnchor is trying to force people to register with their service by making non-compliant transactions from unregistered users cost more and take longer to be confirmed. Unless the database of whitelisted addresses is made public, from the point of view of a non-compliant miner, all transactions are the same; if you’re registered 100% of miners will mine your transaction. But if you’re not registered, you’re going to have to wait.

Unsurprisingly, one of the concerns I heard from the people approached by ChainAnchor was that they didn’t want to be involved in an attempt to get a monopoly over Bitcoin transactions; ethics aside, this scheme could conceivably result in an anti-trust case for ChainAnchor and their partners.

Eliminating Non-Compliant Transactions Entirely

While not in the paper or slides specifically, allegedly the final stage to ChainAnchor is to eliminate unregistered, non-compliant miners from Bitcoin entirely by gradually reducing their profitability until they stop mining or become compliant. Simply bribing miners to only make permissioned blocks may be sufficient by itself - mining is a zero-sum game so if unregistered users respond by registering (or leaving) the extra revenue earned by being compliant may make non-compliant mining unprofitable.

But what happens if users do not leave? For example, users could respond to reduced non-compliant transaction capacity with higher fees - an especially palatable option if layer two scaling solutions like Lightning making users less sensitive to higher fees and longer on-chain confirmation times. In a perfect market without artificial barriers ChainAnchor would in turn have to respond by increasing the bribes paid for compliancy - obviously this could get rather expensive!

Allegedly ChainAnchor was looking into paying miners an additional premium if they mine on top of compliant blocks rather than on top of non-compliant blocks; a possible strategy for miners might be to use compliance as a tie-breaker when determining what side of a fork to mine on. It’s also easy to imagine tools like DoS attacks being used, as well as legal, regulatory, and even social pressure. Finally of course, once a majority of hashing power is on board, a direct 51% attack is always possible (though I’d expect a more subtle approach to be used).

Threat Modeling

However, this is where the evidence available to me gets more sketchy. Rather than talking about what we’re accusing people of planning to do, at this point it’d be more productive to treat this as a threat model exercise: What could an attacker like ChainAnchor do to minimize the cost of making Bitcoin a fully AML compliant, permissioned system?

What’s interesting about this threat is the attacker is trying to change the composition of the mining community itself from less to more regulated, using profitability as a weapon. As defenders - and protocol designers - we have to figure out what kind(s) of miner we’re trying to encourage to achieve our goals, and how to ensure the economic incentives of the system keep those miners profitable.