[protocol spec] Clarify the return type of NoteCommitment^Orchard and usage of it vs NoteCommit^Orchard

[str4d]

One of the outcomes of the NCC audit was that SinsemillaHashToPoint's usage of incomplete addition is now explicitly encoded in its return type P ∪ {⊥} (despite the fact that ⊥ occurring implies the finding of a discrete log relation between independent generators, and thus is assumed negligible). This type flows through the rest of the stack and needs to be handled.

The primary place that this occurs is section 3.2 Notes, which defines NoteCommitment^Orchard in terms of NoteCommit^Orchard, and explicitly handles the ⊥ case; however it is not well-defined as to whether the return type of NoteCommitment^Orchard is P or P ∪ {⊥}. I think the return type should be explicitly P, i.e. asserting that NoteCommit^Orchard does not return ⊥. Then anywhere that a note is being constructed either randomly or from untrusted data, we use NoteCommit^Orchard and handle the ⊥ case; meanwhile the in-memory representation of a note can use NoteCommitment^Orchard.

There are several other places where the protocol specification is unclear as to what should be done:

• Section 4.7.3 Sending Notes (Orchard): "For each Action description, the sender... performs the following steps", which includes "If cm_x = ⊥, return ⊥". This results in an implicit return type {Action description} ∪ {⊥}, but the implicit consumer of the output of these steps is the transaction, which cannot contain ⊥. This section does not specify what the sender should do upon receiving ⊥. Per above, it should either be rewritten to use NoteCommitment^Orchard instead of NoteCommit^Orchard (removing ⊥ from the return type), or explicitly reference section 3.2 for guidance.
• Section 4.8.3 Dummy Notes (Orchard): Same issue ("If cm = ⊥, return ⊥"). This implicit function has a return type {Orchard note} ∪ {⊥}, and is referenced indirectly 4.7.3, also without guidance on what to do in the ⊥ case. It should similarly either use NoteCommitment^Orchard instead of NoteCommit^Orchard, or explicitly reference section 3.2 for guidance.
• Section 4.16 Note Commitments and Nullifiers: DeriveNullifier is defined in terms of the note commitment cm (for clarity, I note that complete addition is used), which cannot be ⊥ here. But in the current spec, it is unclear as to when you can obtain a non-⊥ Orchard note commitment. Per above, I think we should reference NoteCommitment^Orchard here.
• Sections 4.19.2 and 4.19.3 (note decryption): In both sections, if the decrypted note's note commitment (computed via the NoteCommitment function) returns ⊥ (for Orchard), return ⊥. NoteCommitment is undefined, but is clearly intended to refer to NoteCommitment^Orchard. Per above, I think this should use NoteCommit^Orchard instead.