chore(docs): authwit note, not simulating simulations

README.md

@@ -31,7 +31,7 @@ To build Typescript code, make sure to have [`nvm`](https://github.com/nvm-sh/nv
 
 This repository uses CircleCI for continuous integration. Build steps are managed using [`build-system`](https://github.com/AztecProtocol/build-system). Small packages are built and tested as part of a docker build operation, while larger ones and end-to-end tests spin up a large AWS spot instance. Each successful build step creates a new docker image that gets tagged with the package name and commit.
 
-All packages need to be included in the [build manifest](`build_manifest.json`), which declares what paths belong to each package, as well as dependencies between packages. When the CI runs, if none of the rebuild patterns or dependencies were changed, then the build step is skipped and the last successful image is re-tagged with the current commit. Read more on the [`build-system`](https://github.com/AztecProtocol/build-system) repository README.
+All packages need to be included in the [build manifest](build_manifest.yml), which declares what paths belong to each package, as well as dependencies between packages. When the CI runs, if none of the rebuild patterns or dependencies were changed, then the build step is skipped and the last successful image is re-tagged with the current commit. Read more on the [`build-system`](https://github.com/AztecProtocol/build-system) repository README.
 
 It is faster to debug CI failures within a persistent ssh session compared to pushing and waiting. You can create a session with "Rerun step with SSH" on CircleCI which will generate an ssh command for debugging on a worker. Run that command locally and then do
 

barretenberg/cpp/src/barretenberg/bb/readme.md

@@ -9,39 +9,7 @@ This binary will take as input ACIR and witness values described in the IR to cr
 
 ### Installation
 
-1. Install `bbup` the installation script by running this in your terminal:
-
-    ```bash
-    curl -L https://raw.githubusercontent.com/AztecProtocol/aztec-packages/master/barretenberg/cpp/installation/install | bash
-    ```
-
-2. Reload your terminal shell environment:
-
-    macOS:
-    ```bash
-    source ~/.zshrc
-    ```
-
-    Linux:
-    ```bash
-    source ~/.bashrc
-    ```
-
-3. Install the version of `bb` compatible with your Noir version; with **Noir v0.34.0** for example:
-
-    ```bash
-    bbup -v 0.55.0
-    ```
-
-    Check the version compatibility section below for how to identify matching versions.
-
-4. Check if the installation was successful:
-
-    ```bash
-    bb --version
-    ```
-
-If installation was successful, the command would print the version of `bb` installed.
+Follow the installation instructions described [here](../../../../../barretenberg/bbup/README.md#installation).
 
 ### Usage prerequisites
 
@@ -52,6 +20,7 @@ Certain `bb` commands will expect the tool `jq` to already be installed. If `jq
 TODO: https://github.com/AztecProtocol/aztec-packages/issues/7511
 
 For quick reference:
+
 - Noir v0.34.0 <> BB v0.55.0
 - Noir v0.33.0 <> BB v0.47.1
 - Noir v0.32.0 <> BB v0.46.1
@@ -78,23 +47,23 @@ Documented with Noir v0.33.0 <> BB v0.47.1:
 
 2. Prove the valid execution of your Noir program running:
 
-    ```bash
-    bb prove_ultra_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof
-    ```
+   ```bash
+   bb prove_ultra_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof
+   ```
 
 3. Compute the verification key for your Noir program running:
 
-    ```bash
-    bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk
-    ```
+   ```bash
+   bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk
+   ```
 
 4. Verify your proof running:
 
-    ```bash
-    bb verify_ultra_honk -k ./target/vk -p ./target/proof
-    ```
+   ```bash
+   bb verify_ultra_honk -k ./target/vk -p ./target/proof
+   ```
 
-    If successful, the verification will complete in silence; if unsuccessful, the command will trigger logging of the corresponding error.
+   If successful, the verification will complete in silence; if unsuccessful, the command will trigger logging of the corresponding error.
 
 Refer to all available `bb` commands linked above for full list of functionality.
 
@@ -106,24 +75,24 @@ Barretenberg UltraHonk comes with the capability to verify proofs in Solidity, i
 
 2. Prove the valid execution of your Noir program running:
 
-    ```bash
-    bb prove_ultra_keccak_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof
-    ```
+   ```bash
+   bb prove_ultra_keccak_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof
+   ```
 
-    > **Note:** `prove_ultra_keccak_honk` is used to generate UltraHonk proofs with Keccak hashes, as it is what the Solidity verifier is designed to be compatible with given the better gas efficiency when verifying on-chain; `prove_ultra_honk` in comparison generates proofs with Poseidon hashes, more efficient in recursions but not on-chain verifications.
+   > **Note:** `prove_ultra_keccak_honk` is used to generate UltraHonk proofs with Keccak hashes, as it is what the Solidity verifier is designed to be compatible with given the better gas efficiency when verifying on-chain; `prove_ultra_honk` in comparison generates proofs with Poseidon hashes, more efficient in recursions but not on-chain verifications.
 
 3. Compute the verification key for your Noir program running:
 
-    ```bash
-    bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk
-    ```
+   ```bash
+   bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk
+   ```
 
 4. Generate Solidity verifier
- **WARNING:** Contract incomplete, do not use in production!
+   **WARNING:** Contract incomplete, do not use in production!
 
-    ```bash
-    bb contract_ultra_honk -k ./target/vk -c $CRS_PATH -b ./target/hello_world.json -o ./target/Verifier.sol
-    ```
+   ```bash
+   bb contract_ultra_honk -k ./target/vk -c $CRS_PATH -b ./target/hello_world.json -o ./target/Verifier.sol
+   ```
 
 #### Usage with MegaHonk
 
@@ -132,6 +101,7 @@ Use `bb <command>_mega_honk`.
 Refer to all available `bb` commands linked above for full list of functionality.
 
 Note that MegaHonk:
+
 - Generates insecure recursion circuits when Goblin recursive verifiers are not present
 - Will not have a Solidity verifier, as the proving system is intended for use with apps deploying on Aztec only
 

docs/docs/aztec/concepts/accounts/authwit.md

@@ -59,9 +59,10 @@ Adopting ERC20 for Aztec is not as simple as it might seem because of private st
 
 If you recall from the [Hybrid State model](../state_model/index.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
 
-If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](./keys.md). 
+If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](./keys.md).
 
 While this might sound limiting in what we can actually do, the main use of approvals have been for simplifying contract interactions that the user is doing. In the case of private transactions, this is executed on the user device, so it is not a blocker that the user need to tell the executor a secret - the user is the executor!
+
 ### So what can we do?
 
 A few more things we need to remember about private execution:
@@ -194,6 +195,14 @@ The main difference is that we are not setting up an allowance, but allowing the
 
 Also, most uses of the approvals are for contracts where the following interactions are called by the user themselves, so it is not a big issue that they are not as easily "transferrable" as the `permit`s.
 
+:::note
+
+Authwits only work for a single user to authorize actions on contracts that their account is calling. You cannot authorize other users to take actions on your behalf.
+
+:::
+
+In order for another user to be able to take actions on your behalf, they would need access to your nullifier secret key so that they could nullify notes for you, but they should not have access to your nullifier secret key.
+
 ### Other use-cases
 
 We don't need to limit ourselves to the `transfer` function, we can use the same scheme for any function that requires authentication. For example, for authenticating to burn or shield assets or to vote in a governance contract or perform an operation on a lending protocol.

docs/docs/aztec/concepts/accounts/index.md

@@ -107,10 +107,11 @@ Notice that the Signerless wallet doesn't invoke an entrypoint function of an ac
 
 :::info
 Entrypoints for the following cases:
+
 - if no contract entrypoint is used `msg_sender` is set to `Field.max`.
 - in a private to public entrypoint, `msg_sender` is the contract making the private to public call
 - when calling the entrypoint on an account contract, `msg_sender` is set to the account contract address
-:::
+  :::
 
 ### Account initialization
 
@@ -127,12 +128,20 @@ Users will need to pay transaction fees in order to deploy their account contrac
 Account contracts are also expected, though not required by the protocol, to implement a set of methods for authorizing actions on behalf of the user. During a transaction, a contract may call into the account contract and request the user authorization for a given action, identified by a hash. This pattern is used, for instance, for transferring tokens from an account that is not the caller.
 
 When executing a private function, this authorization is checked by requesting an _auth witness_ from the execution oracle, which is usually a signed message.
-The PXE is responsible for storing these auth witnesses and returning them to the requesting account contract.
+The user's Private eXecution Environment (PXE) is responsible for storing these auth witnesses and returning them to the requesting account contract.
 Auth witnesses can belong to the current user executing the local transaction, or to another user who shared it out-of-band.
 
 However, during a public function execution, it is not possible to retrieve a value from the local oracle. To support authorizations in public functions, account contracts should save in contract storage what actions have been pre-authorized by their owner.
 
-These two patterns combined allow an account contract to answer whether an action `is_valid` for a given user both in private and public contexts.
+These two patterns combined allow an account contract to answer whether an action `is_valid_impl` for a given user both in private and public contexts.
+
+You can read more about authorizing actions with authorization witnesses on [this page](./authwit.md).
+
+:::info
+
+Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. For example, a user will need to authorize an action, even if it is only a simulated operation from a contract. Simulating a `transfer_from` call will require a signature in a Schnorr account or will require 2FA authorization in the case of 2FA account.
+
+:::
 
 ### Encryption and nullifying keys
 

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md

@@ -14,7 +14,7 @@ For a guide on using authwit in Aztec.js, [read this](../../js_apps/authwit.md).
 
 ## Introduction
 
-Authentication Witness is a scheme for authentication actions on Aztec, so users can allow third-parties (eg protocols or other users) to execute an action on their behalf.
+Authentication Witness (authwit) is a scheme for authentication actions on Aztec, so users can allow third-parties (eg other contracts) to execute an action on their behalf. Authwits can only authorize actions for contracts that your account is calling, they cannot be used to permit other users to take actions on your behalf.
 
 How it works logically is explained in the [concepts](../../../../aztec/concepts/accounts/authwit.md) but we will do a short recap here.
 
@@ -175,7 +175,7 @@ In the snippet below, this is done as a separate contract call, but can also be
 
 We have cases where we need a non-wallet contract to approve an action to be executed by another contract. One of the cases could be when making more complex defi where funds are passed along. When doing so, we need the intermediate contracts to support approving of actions on their behalf.
 
-This is fairly straight forward to do using the `auth` library which includes logic for updating values in the public auth registry. Namely, you can prepare the `message_hash` using `compute_authwit_message_hash_from_call` and then simply feed it into the `set_authorized` function (both are in `auth` library) to update the value. 
+This is fairly straight forward to do using the `auth` library which includes logic for updating values in the public auth registry. Namely, you can prepare the `message_hash` using `compute_authwit_message_hash_from_call` and then simply feed it into the `set_authorized` function (both are in `auth` library) to update the value.
 
 When another contract later is consuming the authwit using `assert_current_call_valid_authwit_public` it will be calling the registry, and spend that authwit.
 

docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md

@@ -49,6 +49,12 @@ The `AccountActions` module provides default implementations for most of the acc
 
 For our account contract, we will take the hash of the action to authorize, request the corresponding auth witness from the oracle, and validate it against our hardcoded public key. If the signature is correct, we authorize the action.
 
+:::info
+
+Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. For example, a user will need to authorize an action, even if it is only a simulated operation from a contract. Simulating a `transfer_from` call will require a signature in a Schnorr account or will require 2FA authorization in the case of 2FA account.
+
+:::
+
 ### Fee Abstraction
 
 The `FeePayload`, being distinct from the `AppPayload`, allows for fee abstraction, meaning the account paying the fee for the transaction can be different than the account that is initiating the transaction. This is also useful for maintaining privacy, as fee payments on the network must be public. For example, Alice could pay a relayer transaction fees in private, and the relayer could pay the transaction fee in public. This also allows for accounts without Fee Juice to use another asset to pay for fees, provided they can find a relayer willing to accept the asset as payment (or do it for free).

noir-projects/aztec-nr/README.md

@@ -15,12 +15,12 @@
   </p>
 </div>
 
-
 # Aztec.nr
 
 `Aztec-nr` is a [Noir](https://noir-lang.org) framework for smart contracts on [Aztec](aztec.network).
 
 ### Directory Structure
+
 ```
 .
 ├── aztec               // The core of the aztec framework
@@ -47,24 +47,26 @@ easy_private_state = { git = "https://github.com/AztecProtocol/aztec-nr", tag =
 value_note = { git = "https://github.com/AztecProtocol/aztec-nr", tag = "master" , directory = "value-note" }
 ```
 
-
 ## Prerequisites
+
 To use `Aztec.nr` you must have [Noir](https://noir-lang.org/) installed. Noir is a general purpose programming language for creating zero-knowledge-proofs. `Aztec.nr` supercharges the Noir language with Aztec Smart Contract capabilities.
 
 ### Quick Installation
-The fastest way to install is with [noirup](https://noir-lang.org/docs/getting_started/installation/#installing-noirup).
+
+The fastest way to install is with [noirup](https://noir-lang.org/docs/getting_started/quick_start).
 
 To use `Aztec-nr` the `aztec` version of `Noir` is required (Note; this version is temporarily required if you would like to use `#[aztec()]` macros).
 
 Once noirup is installed, you can run the following:
+
 ```bash
 noirup -v NARGO_VERSION_COMPATIBLE_WITH_YOUR_SANDBOX
 ```
 
 Replace `NARGO_VERSION_COMPATIBLE_WITH_YOUR_SANDBOX` with the version from the output of `aztec-cli get-node-info`:
+
 ```bash
 aztec-cli get-node-info
 ```
 
 For more installation options, please view [Noir's getting started.](https://noir-lang.org/docs/getting_started/installation/other_install_methods)
-