[Speaking for myself. I’m also tapping this out on a tiny phone screen while on holiday, so this comment might not be as polished as usual for me.]
As others have pointed out, @nuttycom and I voiced our opposition to this proposal on Arborist calls. I also did so at ZK Proof 6 where the cryptographic protocol was presented. [Edit: I misremembered also doing so in a panel discussion in Zcon V, but I was confusing that with a private call preparing for Zcon V.]
I will refer to it as a surveillance protocol, because it enables surveillance; that is its purpose. Calling it a “compliance” protocol is misleadingly vague as to what is being “complied” with.
I was not aware that a USD 600,000 grant was being considered. Frankly, that seems an absurdly high amount for the work proposed, even aside from the critical privacy objections (which I’ll expand on below). I would have expected that given the size of the grant, the obviously controversial subject matter, and the protocol complexity issues, that the ZCG Committee would have sought input from the protocol designers and full node implementors at ECC and ZF. Speaking for myself, I consider it a failure of governance that they did not.
ECC and ZF don’t have any veto over what can be funded, which is how it should be, but it just makes no sense to me that such a grant was approved without seeking our input. There is huge opportunity cost in spending USD 600,000 on this rather than other projects in the Zcash ecosystem. There is also a potential reputational cost to Zcash in having funded this work even if (as I think is likely) it is never deployed.
The first time I heard the cryptographic detail of what Qedit was proposing was in Pablo’s talk at ZK Proof 6. I was actually shocked at how bad it was. There is a single key for each surveilled token that if compromised, would leak its entire transaction graph. I cannot see how such keys could be kept secure; they are too much of a target. We won the arguments against such concentration of surveillance authority in previous Crypto Wars, as described in [Keys Under Doormats, 2015]. Almost all of those arguments, and others (the extreme difficulty of implementing correct zk circuits, for instance) are equally valid in this context. We know that even well-funded intelligence agencies or large corporations are not in practice able to keep high-value secrets.
The idea that this is okay because we have transparent addresses does not hold water. Transparent addresses were an explicit compromise to enable use of Bitcoin libraries and adoption on exchanges that already supported Bitcoin-derived altcoins. With hindsight, it isn’t clear that this was a good trade-off. If I could go back in time I would recommend that we take a different approach, in which all addresses that have a transparent component also have a shielded component. In my opinion, some of the arguments against having transparent functionality in the protocol are valid, and we should be working toward removing it. The progress in that direction has been significantly slower than I would have liked.
In any case, to me it is significantly worse to have a protocol that promises privacy against anyone but the issuer and the surveillance state, but where that privacy fails catastrophically in the case of key compromise, than it is to have an explicitly transparent protocol.
It is also objectionable that the proposal adds verifiable encryption that benefits the surveillance authorities without providing any direct benefit to users (e.g. in strengthening the properties of consensual selective transparency features). I am concerned by the resulting effects on protocol complexity, especially if this verifiable encryption is post-quantum (which is important in order to maintain the current property that Zcash has post-quantum privacy when addresses are treated as shared secrets). If the encryption to the surveillance keys is post-quantum but the ordinary note encryption is not, I object. If the anonymity set is split in order to avoid imposing high circuit and/or bandwidth costs on non-surveilled tokens, I object: this was specifically avoided in the “vanilla” ZSA design because it was not clear that ZSA usage would have sufficient transaction volume initially. If this proposal interferes with possibilities for moving note ciphertexts off-chain to improve scalability, I object. If it makes potential improvements to reduce the impact of key compromise (approximating forward secrecy) more difficult, I object.
The “slippery slope” argument against adding surveillance to the protocol is very persuasive to me, especially in the current regulatory and political environment. Adding surveillance of some tokens allows regulators to apply pressure to extend that surveillance to other Zcash tokens. As someone who may be a direct target of such pressure up to and including legal threats, I don’t consent to this!
Any facility to allow the state to surveil financial transactions will be abused. It is not a matter of “whether” it will be abused. Recently, for example, it was proposed in the UK to routinely surveil bank accounts of benefits claimants, in order to detect so-called “benefits fraud”. In fact, fraud is a negligible issue and the vast majority of errors in paying benefits are made by the benefits authority. The proposal was actually part of an agenda of denigrating and scapegoating benefits claimants, and would have disproportionately affected disabled claimants, putting them in constant fear of being made destitute.
We live at a time when the mechanisms of democracy are under serious threat in several countries, and where we already have unethical laws attacking basic rights such as bodily autonomy. It is naive to pretend otherwise.
