ZIP 231: Memo Bundles #824
Conversation
|
EDIT: Moved comments to #627 (comment) (to keep discussion in the issue, not the PR). |
|
EDIT: Moved comments to #627 (comment) |
|
Rebased on |
|
Comments above were from today's R&D meeting (I intended to leave them collectively as a review, but forgot to click the right GitHub buttons). |
zips/zip-0231.md
Outdated
|
|
||
| The symmetric encryption key for a memo is derived from its `memo_key` as follows: | ||
|
|
||
| encryption_key = PRF^{expand}_{memo_key}([0xE0] || nonce) |
There was a problem hiding this comment.
Clarify where else the 0xEO constant needs to be documented.
zips/zip-0231.md
Outdated
| TODO: Decide whether to permit an optimised encoding for a fully-pruned memo | ||
| bundle that just contains `memo_bundle_digest`. |
There was a problem hiding this comment.
What if we wrote the pruned value prior to the nonce, and then just used 0xFFFFFFFFFFFFFFFF for the "fully pruned" indicator? Then, the nonce and nMemo* would only be present if the pruned value is not equal to that value.
This could also help with indistinguishability: instead of omitting the memo bundle entirely, all "no memo" transactions could instead represent themselves as fully pruned; the recipient would be able to distinguish between "my memo has been pruned" and "there is no memo" by inspecting the flag byte in their output.
There was a problem hiding this comment.
In thinking about and discussing pruning with @str4d and @arya2, several concerns arose related to pruning.
- If pruning is permitted in the network protocol format, what does the behavior of nodes need to be when they receive a pruned transaction? Do they continue attempting to retrieve the full transaction data from other peers? If so, does this create a potential situation where nodes have to keep track of which peers they've re-requested transactions from when attempting to restore complete memo data? How long do nodes need to continue retrying in order to ensure that they have obtained all the memo data that is available?
- Does pruning introduce a risk to the usability of memos on the network, due to a tragedy of the commons where node operators prefer to prune memos to save on storage and bandwidth, and as a consequence data availability suffers?
- Is there a potential adversarial case to consider, where some party cheaply runs a bunch of nodes on the network, all of which prune memo data when propagating transactions, thereby directly attacking data availability?
It's my personal opinion that the risks and complexity introduced by the pruning functionality make it infeasible to implement pruning in NU7. It might be something that can be introduced at a later date, but given the other functionality that we're currently aiming to support in NU7, we should attempt to avoid any changes that impact the network protocol if at all possible.
nuttycom
added
NU7 proposal
consensus
zips/zip-0231.md
Outdated
| the sender addresses (to give the recipient a guarantee that the address is | ||
| controlled by a sender of the transaction). These Authenticated Reply Addresses | ||
| require zero-knowledge proofs, and for the Orchard protocol these proofs are too | ||
| large to fit into a 512-byte memo field. |
There was a problem hiding this comment.
Another use case we should be concerned with here is coin voting - can the proofs in Hanh's coin voting protocol (along with the amount being voted with) fit into a memo? I think extended memos can provide an ideal mechanism for election organizers to collect the secret ballots.
| memo_chunk_digest = H(AEAD(MemoChunk, memo_key)) | ||
| memo_bundle_digest = H(concat(memo_chunk_digests)) |
There was a problem hiding this comment.
This is intended to commit only to the effecting data, and to exclude any pruning metadata.
Co-authored-by: Daira-Emma Hopwood <daira@electriccoin.co> Co-authored-by: Kris Nuttycombe <kris@electriccoin.co>
Co-authored-by: Daira-Emma Hopwood <daira@electriccoin.co> Co-authored-by: Kris Nuttycombe <kris@electriccoin.co>
Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
Signed-off-by: Daira-Emma Hopwood <daira@katava.local>
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
Part of #627.