Something that came up is that this will require a keystone firmware update. So deployment strategy needs to be adapted accordingly.

I am testing the UX of keystone firmware updates from my phone, and what we can do to make ZODL alert a user if their keystone isn't updated. There is not yet keystone version negotiation in ZODL, I don't yet have an answer if its possible without a keystone firmware update.

An alternative design would be to adapt QR to not need a note commitment change, e.g. via editing the binding signature which is purely wallet only

An alternative design would be to adapt QR to not need a note commitment change, e.g. via editing the binding signature which is purely wallet only

I see several problems with this:

• There is only one Orchard binding signature per transaction, but multiple output notes (in particular, zcash_client_backend will shard change into multiple notes for note management purposes). So any process for binding note data into it would need to have visibility into all output notes.
• We cannot fix the above by relying on the transaction creator to be both the sender and recipient (and knowing all the private details), because in the proposed Phase 2, the external recipient won't know the change note details, and thus can't account for them when checking the note binding.
• Binding signatures are not included in CompactBlocks, so light client recipients can't check the binding properties of their notes.

It is necessary that recipients can check their notes are correctly bound, and reject 0x03 note plaintexts if not, as otherwise the sender is not correctly ensuring the semantics of that note plaintext format, and may not be getting the QR properties they are assuming (since those QR properties are entirely controlled by the sender).

Thank you for all the comments! I'll make changes accordingly.

There is only one Orchard binding signature per transaction, but multiple output notes (in particular, zcash_client_backend will shard change into multiple notes for note management purposes). So any process for binding note data into it would need to have visibility into all output notes.

Your right! We could use the randomness for the signature from esk, which would be action-specific.

The same compact block problem would apply, but the trade-off is somewhat:

• Make note lead plaintext byte change, and require a keystone update
• Don't do a lead plaintext byte change, and pack somewhere else
  • Memo
  • randomness of the signature from esk

The only way I can see for how to safely pack data into a compact block without a lead plaintext byte change would be the memo. A candidate strategy would be on receipt of a tx, the wallet downloads the full tx or QR data to determine if its a QR note.

Perhaps the trade-off looks like:

• Require keystone firmware update for users + have KS wallets avoid QR until they update.
• Optimistically make wallets do QR via another field
  • At first wallet software may not be able to detect QR from external notes easily
  • Adapt wallet sync to download more data, similar to what is already done with full memo download. (Separate to this, but we already have demo's for using PIR to hide leakage of full memo downloads to a single server)

The only way I can see for how to safely pack data into a compact block without a lead plaintext byte change would be the memo.

CompactBlocks don't contain memos. They are explicitly truncated off to save bandwidth. Besides the fact that changing the truncated length would be a very invasive change within the stack, without an associated tx format change we won't know which ones have the extra data so we'd need to include partially-truncated memos for every participant, creating a type safety nightmare.

Ah your right, more accurate would be "only way to detect QR that I can see, in the existing light client protocol, and no note plaintext lead byte change". (Since the full memo is downloaded in the current light client protocol, after trial decrypt)

An alternative design would be to adapt QR to not need a note commitment change, e.g. via editing the binding signature which is purely wallet only

This can't work. The current note commitment scheme is not post-quantum binding and that's a major part of the problem to be solved, so I think this comment indicates a misunderstanding of what that problem is.

We will not change the semantics of the note plaintext without changing the lead byte. The lead byte is how the creator of the note communicates to the recipient what the semantics are. Also nothing is to be gained by not changing the lead byte, because the recipient would in that case compute the wrong commitment, so it would ignore the note. It does not matter for compatibility whether it ignores the note because of computing the wrong commitment, or it ignores it because of an unrecognized lead byte — but the former is less explicit and less easily debuggable, which is why we will not do it that way.