specification: file organization in protocol spec #4485
Conversation
TalDerei
added
the
ecc-component-remediated
TalDerei
changed the title
| @@ -5,6 +5,6 @@ Plaintext notes contain: | |||
| * the value to be transmitted which consists of an integer amount $v$ along with a scalar (32 bytes) $ID$ identifying the asset. | |||
| * $rseed$, a 32-byte random value, which will later be used to derive the note blinding factor used for the | |||
| note commitment and an ephemeral secret key. | |||
| * the destination address, described in more detail in the [Addresses](../addresses_keys/addresses.md) section. | |||
| * the destination address controlling the note, described in more detail in the [Addresses](../addresses_keys/addresses.md) section. | |||
There was a problem hiding this comment.
In the note plaintext section of the audit, there was some confusion about pk_d. Comparing the spec against the code reveals some incongruences:
- the
Addressstruct definespk_das the public key used for the payment address, but the spec definespk_d
as the diversified transmission key. - the
Notestruct consists of value, rseed, address, and transmission_key but the spec is missing the diversified transmission key.
| @@ -1,3 +1,17 @@ | |||
| # Note Ciphertexts | |||
There was a problem hiding this comment.
Note encryption was previously unspecified.
| @@ -8,6 +8,14 @@ attaches a *detection key* to each address, allowing a user to outsource | |||
| probabilistic transaction detection to a relatively untrusted third-party | |||
| scanning service. | |||
|
|
|||
| ## Privacy Implications | |||
There was a problem hiding this comment.
Added privacy implications associated with detection keys based on comments made in component Y.
| @@ -14,7 +14,7 @@ The note commitment is generated using rate-5 Poseidon hashing with domain separ | |||
| The note commitment is then constructed using the above domain separator and | |||
| hashing together the above contents along with the note blinding factor $rcm$: | |||
|
|
|||
| `note_commitment = hash_5(ds, (rcm, v, ID, B_d, pk_d))` | |||
| `note_commitment = hash_6(ds, (rcm, v, ID, B_d, pk_d, ck_d))` | |||
There was a problem hiding this comment.
docs/protocol/src/SUMMARY.md
Outdated
| @@ -17,7 +17,6 @@ | |||
| - [Group Hash](./crypto/decaf377/group_hash.md) | |||
| - [Test Vectors](./crypto/decaf377/test_vectors.md) | |||
| - [Randomizable Signatures](./crypto/decaf377-rdsa.md) | |||
| - [Key Agreement](./crypto/decaf377-ka.md) | |||
There was a problem hiding this comment.
we should actually keep this section and link to the implementation
|
@redshiftzero this doesn't have an associated issue attached to it |
|
this is a staging area for spec-related changes, and we'll focus on addressing the rest of the spec changes once phase 2 is unblocked. |
| @@ -1 +0,0 @@ | |||
| # CommunityPoolDeposit | |||
There was a problem hiding this comment.
The audit (correctly) pointed out that we lack complete documentation of the protocol, and have these stub pages in the protocol spec. We should remove pages that are no longer relevant, but I think in every case the stub pages are relevant, i.e. the CommunityPoolDeposit does exist as an action, and as such should be ideally documented in the protocol specification. So I think the action here is to fill these pages out (not in this PR because that's a significant chunk of work) instead of deleting them. One thing we could do is just make a list of pages that should be filled out in an issue.
There was a problem hiding this comment.
sounds great, will revert the deleted pages and open a relevant PR.
Describe your changes
Several parts of the protocol are not specified, while being referred to in other parts of the documentation. We should remove these empty patches in our protocol spec, and use this PR as a guiding reference of what sections were removed as we periodically fill them in over time. @conorsch can you help better format the docs?
This references components X and Y in the ECC audit log. Auxiliary to this is component Z, which should probably be (but currently is not) captured here since they're also spec-related changes.
This also captures supplemental spec changes based on specific spec-related comments made in the audit.
Issue ticket number and link
Checklist before requesting a review