Censorship Resistance of Revocation

[kimdhamilton]

From @ChristopherA on July 9, 2017 22:44

Related to #3 "Censorship Resistance in OP_RETURN Transactions", as per @sipa's comment WebOfTrustInfo/btcr-hackathon-2017#2 (comment) we also want to have as goal to have censorship resistance for the revocation transaction.

You want censorship resistance for the revocation, not the publishing. If you're being
censored for registering, just don't start using the identity and try again. If your revocation
is censored, your identity may have been stolen.

So walking through the scenarios:

Scenario One: Clearly if your DID is broadly distributed and easily identifiable (as it would be in the case if you have a DDO pointer as per #2, or possibly even with the TX1 proposal in #24), then a miner might choose to arbitrarily censor any revocation transactions associated with that DID. A counter-argument might be that there are lots of miners, so as long as at least one honest miner a day accepts a transaction fee to revoke, you can have at least a 1 day revocation window. This is superior to many certificate revocation scenarios today that are not very reliable at all or require very centralized authorities.

Scenario Two: However, if it is a DID is without an op_return pointer to the DDO or has other identifiable characters (aka a "default DDO") and you are using a simple address as output serving as the revocation signal, this is harder to censor. The miner must know about your DID to find the addresses to censor, requiring them to have received it from someone, or possibly by crawling the net looking for verifiable claims. I'm not sure that this scenario is much different than the current correlation efforts by bitcoin analysis firms today. Thus if this is a problem, we may be able to leverage someday the same efforts to increase fungibility to also increase censorship resistance.

Finally, @sipa says:

Regardless of how you encode things, if your identifier is short, it means that the
revocation is detectable for everyone.

I'm not sure I agree with that statement.

In Scenario One the key problem is that the DID is identifiable and broadly distributed, not that the ID is short or long. Here censorship resistance against miners is harder.

However in Scenario Two both the DID and its future revoking transaction are not easily identifiable or correlatable thus it requires the censor to have knowledge of your DID from some other source — in this case, again the difference between searching for a short identifier or a long one is minimal. If the censors are miners, they not only must have searched or collected your identifier, they must also resist all other miners who are not interested in censoring the revocation transaction, which is a general Bitcoin problem, not a DID specific one.

cc: @jonasschnelli @veleslavs

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#25

[kimdhamilton]

From @ChristopherA on July 10, 2017 0:8

See also @petertodd's comments in WebOfTrustInfo/btcr-hackathon-2017#2 (comment)

[kimdhamilton]

From @rxgrant on July 10, 2017 2:6

If we were going to invert the responsibilities for discovering the communication resources that DDOs describe (i.e. "service endpoints": names + protocols + IPaddrs), and were instead going to use DIDs merely for verifying signatures, then we could consider pay-to-contract options that offer higher censorship resistance. We can leave this choice to each DID registrant, but it seems that stuffing data in DDOs is a major feature (which even the otherwise-stealthy deterministic-DDO case will support, via OP_RETURN), and that revocation design constraints should assume the common case of a DID pointing to a DDO in an unavoidably public way.

We could even support time-lock-stealth revocations, although the logic of trying to hide the revocation is similar to the broken logic of blacklisting, in that your attacker clearly knows what's going on before you do (in all but the "lost my phone" case), and can arrange countermeasures using this information advantage. The attacker knows the chain of transactions that you would revoke on, and would have plenty of time to arrange a preferential censoring relationship with whichever miners would support it.

What this means for the protocol is that if we are indeed aiming for revocation censorship resistance (beyond merely looking for an honest miner, or waiting for opcodes to implement a revocation sidechain), then the only option is to support stealth pay-to-contract addresses initiated from any transaction history (instead of occurring on the history of the DID). The work to unlock these would still need to be shared with peers in a censorship-resistant way using something like a sidechain, but that's trustless and only requires spam prevention, not transaction ordering.

If we figure out how to do that for revocations, then we can point to DDO data the same way.