# \[Legacy] PoW Anonymity Revoking

**NOTE: THIS IS LEGACY INFORMATION ON A DEPRECATED VERSION.**

In Version 0.1.0 (see [Version 0.1.0](https://docs.blanksquare.io/protocol-details/version-changelog/version-0.1.0)) the Anonymity Revoking mechanism as described in [Anonymity Revokers](https://docs.blanksquare.io/protocol-details/design-against-bad-actors/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](https://docs.blanksquare.io/protocol-details/design-against-bad-actors/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](https://docs.blanksquare.io/protocol-details/version-changelog/version-0.1.0)). Subsequent versions will replace PoW AR with the mechanism described in [Anonymity Revokers](https://docs.blanksquare.io/protocol-details/design-against-bad-actors/anonymity-revokers).

### Technical Details <a href="#pdf-page-8nozh8o67afavpwaiozg-technical-details" id="pdf-page-8nozh8o67afavpwaiozg-technical-details"></a>

As introduced in [Notes and Accounts](https://docs.blanksquare.io/protocol-details/notes-and-accounts) each user holds a secret `id`that 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 `L`is the anonymity parameter (the larger the `L`the 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 `d` 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 `L`is, the more resources and time must be invested, hence the name "PoW Anonymity Revoking".

### Impact on Circuits <a href="#pdf-page-8nozh8o67afavpwaiozg-impact-on-circuits" id="pdf-page-8nozh8o67afavpwaiozg-impact-on-circuits"></a>

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)`


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.blanksquare.io/protocol-details/design-against-bad-actors/pow-anonymity-revoking.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.