MIT ChainAnchor - Bribing Miners to Regulate Bitcoin

Apr 21, 2016

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:

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.

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.

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.