The censorship-resistance property here doesn&#x27;t require a blockchain, just a Merkle tree. See the article and discussion here: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10844612" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10844612</a> (in particular my comment there).<p>Specifically, a miner can refuse to encode your transaction just as much as your first PGP server can refuse to accept the sent key. (PGP actually has a strong advantage here, since it&#x27;s easy to push your revocation to all the servers on your own, immediately, but you yourself are extremely unlikely to mine a block with your own transaction, unless the network is otherwise broken security-wise.) So the primary thing to worry about is a server that refuses to provide information on the revocation, once it has hit the shared database. But that can be solved by just having cryptographic monotonicity, that no transactions can be removed once encoded; you don&#x27;t need the blockchain&#x27;s specific power to order transactions and resolve conflicts. And a Merkle tree provides monotonicity. Certificate Transparency works this way.<p>I agree that the PGP keyserver infrastructure doesn&#x27;t currently provide this; I&#x27;m just asserting that it doesn&#x27;t take a blockchain to provide it, and there are significant downsides (like waiting for a transaction to commit) to taking that approach.<p>One thing that a blockchain <i>would</i> provide is the ability to revoke one key in favor of another, and uniquely determine which key supersedes the old. But it&#x27;s not clear how important that ability is and whether it justifies the tradeoffs of a blockchain approach.