PoW Anonymity Revoking

In Version 0.1.0 (see Version 0.1.0) the Anonymity Revoking mechanism as described in Anonymity Revokers is not yet available (it's planned for subsequent releases). Instead this version features a mechanism that we call "PoW Anonymity Revoking" (Proof of Work Revoking) in which any actor can reveal traces of particular users, given that they invest appropriate computational resources (similarly as when mining blocks in Bitcoin). Note that this does not guarantee the level of privacy achieved by the Anonymity Revokers system, however Version 0.1.0 is considered a beta-release with limited functionality and with safety precautions included (see Version 0.1.0). Subsequent versions will replace PoW AR with the mechanism described in Anonymity Revokers.

Technical Details

As introduced in Notes and Accountseach user holds a secret idthat represents their secret key of their Shielder account. In the Version 0.1.0 upon creating a new account the user publicly reveals h_id = hash(id) — one can think of this as a public key of this shielder account.

Subsequently, upon each operation involving this account, the user is forced to include a digest (called id_hiding) of the form hash(h_id, nonce)where nonce is chosen by the user at random from an interval [0, 2^L)where Lis the anonymity parameter (the larger the Lthe more work is required to deanonymize).

Now, given the h_id of a particular user, it is possible to test if a given transaction was issued by this user or not. Specifically, if the AR digest of a transaction is then by trying if any of hash(h_id, nonce) == d for all the nonces in the specified range, one can check if this transaction is from this user or not. By repeating this test on all transactions sent to the shielder contract it is possible to track a given user activities. Note however that the more transactions and the higher the Lis, the more resources and time must be invested, hence the name "PoW Anonymity Revoking".

Impact on Circuits

To support PoW AR in circuits we must force the user to include the correct "revealing" digest as part of each of their transactions. This is quite easy, the digest becomes one of the public inputs and we verify the following constraint on it:

• 0 <= nonce < 2^L

• id_hiding == hash(hash(id), nonce)