Merge branch 'master' into janb/liquidity-mining-experiment

yellow-paper/docs/decentralisation/_category_.json

@@ -1,6 +1,6 @@
 {
   "label": "Decentralisation",
-  "position": 3,
+  "position": 4,
   "link": {
     "type": "generated-index",
     "description": "Decentralisation..."

yellow-paper/docs/gas-and-fees/_category_.json

@@ -1,6 +1,6 @@
 {
   "label": "Gas & Fees",
-  "position": 2,
+  "position": 3,
   "link": {
     "type": "generated-index",
     "description": "Gas and fees on the Aztec network..."

yellow-paper/docs/private-message-delivery/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Private Message Delivery",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Delivering messages privately on the Aztec network..."
+  }
+}

yellow-paper/docs/private-message-delivery/encryption-and-decryption.md

@@ -0,0 +1,6 @@
+---
+sidebar_position: 2
+---
+
+# Encryption and Decryption
+

yellow-paper/docs/private-message-delivery/note-discovery.md

@@ -0,0 +1,15 @@
+---
+sidebar_position: 3
+---
+
+# Note Discovery
+
+## Requirements
+
+When users interact with contracts they will generate and publish encrypted notes for other network participants. In order for a user to consume those notes, they need to identify, retrieve and decrypt them. The total number of encrypted notes published by the network will be substantial, making it infeasible for some users to simply retrieve every note and attempt a naive brute-force decryption. For this reason, those users will want to utilize a note discovery protocol to privately identify and provide a much smaller subset of notes for the user to decrypt.
+
+A number of techniques currently exist to perform this task with various compromises of levels of privacy and the required amounts of computational effort and/or network bandwidth. This is a field into which a lot of research if being conducted so our approach is not to dictate a specific technique but to put in place the necessary abstractions such that users can select their preferred protocol and new techniques can be integrated in the future.
+
+## Tag Abstraction
+
+When applications produce notes they will need to call a protocol defined function within the account contract of the recipient and request that a tag be generated. From the protocol's perspective, this tag will simply be a stream of bytes relevant only to the recipient's note discovery protocol. It will be up to the account contract to constrain that the correct tag has been generated and from there the protocol circuits along with the rollup contract will ensure that the tag is correctly published along with the note.

yellow-paper/docs/private-message-delivery/private-message-delivery.md

@@ -0,0 +1,38 @@
+---
+sidebar_position: 1
+---
+
+# Private Message Delivery
+
+## Requirements
+
+Maintaining the core tenet of privacy within the Aztec Network imposes a number of requirements on it. If Alice executes a function that generates state for Bob:
+
+1. Alice will need to encrypt that state such that Bob, and only Bob is able to decrypt it.
+2. Alice will need to broadcast the encrypted state so as to make it available for Bob to retrieve.
+3. Alice will need to broadcast a 'tag' alongside the encrypted state. This tag must be identifiable by Bob's chosen [note discovery protocol](./note-discovery.md) but not identifiable by any third party.
+
+Fulfilling these requirements will enable users to privately identify, retrieve, decrypt and spend their application state.
+
+## Constraining Message Delivery
+
+The network will constrain:
+
+1. The encryption of a user's note.
+2. The generation of the tag for that note.
+3. The publication of that note to the correct data availability layer.
+
+Constraining [note encryption](./encryption-and-decryption.md) and tagging will be done through protocol defined functions within a user's account contract. The advantages of this approach are:
+
+1. It enables a user to select their preferred [note discovery protocol](./note-discovery.md)  and/or encryption scheme.
+2. It ensures that notes are correctly encrypted with a user's public encryption key.
+3. It ensures that notes are correctly tagged for a user's chosen [note discovery protocol](./note-discovery.md) .
+4. It provides scope for upgrading these functions or introducing new schemes as the field progresses.
+5. It protects applications from malicious account contracts providing unprovable functions.
+
+Constraining publication to the correct data availability layer will be performed via a combination of the protocol circuits and the rollup contract on L1.
+
+## User Handshaking
+
+One function that is useful regardless of the preferred note discovery and encryption schemes is for user's to be notified when they have been sent a note from another user for the first time. To achieve this we will deploy a 'user handshaking' contract that can be used to create a private note for a recipient containing the sender's details (e.g. public key). Network participants will be able to retrieve these notes, decrypt them and use the contents to guide them in the generation of tags of notes to retrieve.
+