[ZIP-230] v6 transactions, including ZSAs

[dconnolly]

fixes #686

[daira]

Suggested change

	|``96 * nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV6[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per |
	|``96 * nSpendsSapling`` |``vSpendsSapling`` |``SpendDescriptionV5[nSpendsSapling]`` |A sequence of Sapling Spend descriptions, encoded per |

There's no reason for this to be different from v5. We can add a note explaining that.

[daira]

Suggested change

	|``756 * nOutputsSapling`` |``vOutputsSapling`` |``OutputDescriptionV6[nOutputsSapling]``|A sequence of Sapling Output descriptions, encoded per |
	|``756 * nOutputsSapling`` |``vOutputsSapling`` |``OutputDescriptionV5[nOutputsSapling]``|A sequence of Sapling Output descriptions, encoded per |

[nuttycom]

Something that I wanted to get in for v5 transactions, but that we didn't do because we were already pushing the complexity budget, is decouple memos from outputs. The idea here is that the action would, instead of a memo in the encCiphertext, include a 32-byte key. The transaction would then, at the top level, contain a field that is a length-prefixed array of 512-byte memo ciphertexts. This would allow multiple memos to be decryptable by a single recipient, or a single memo to be decrypted by multiple recipients without increasing the size of the transaction, or any combination in between. Decoupling the memos from the outputs could open up new use cases for including longer message, and could also in common cases limit chain growth by eliminating the need to add an additional 512-byte payload for each recipient; the "standard" would likely be to include a single memo per transaction. At present, if a user wants to send more than a single 512-byte payload to their counterparty, they are compelled to bloat the chain with extra actions; segregating the memos eliminates this source of chain growth.

If we did decouple the memos in this fashion, we'd probably want to modify ZIP 317 to add a per-memo fee amount (potentially decreasing the marginal fee per action at the same time).

[nuttycom]

Oops, I'd meant to put this comment into the Orchard section, but I suppose that it could apply to Sapling as well.

[dconnolly]

ZIP number reserved: 230

[teor2345]

Do we want to specify coinbase transaction heights here, or is it ok to leave it in the detailed rules?

[teor2345]

Suggested change

	|``8`` |``fee`` |``int64`` |The fee to be paid by this transaction, in zatoshis. |
	|``8`` |``fee`` |``int64`` |The non-negative fee to be paid by this transaction, in zatoshis. |

[teor2345]

Or are negative values allowed in coinbase transactions?

[daira]

Teor's comment refers to a brainwave I had during the ZIP sync today, which is that a negative fee in a coinbase transaction could represent the fees collected from other transactions in the block. This would be more regular, because:

• every transaction would balance exactly;
• the sum of fee fields in each block would be zero.

[teor2345]

Is it worth making the fees and value balances a CompactSize to save 15+ bytes per transaction?

[daira]

I have no strong opinion about this, but a possible argument for doing so is that if we increase the range of amounts in order to accommodate ZSA bridges with other coins that have a larger range, then using CompactSizes would help to mitigate the cost of that (when the full range is not actually used, or for ZEC).

[nuttycom]

A note from zip sync: we should start thinking about setting a horizon for recovery of notes and memos from the chain via trial decryption. 10 years maybe?

[nuttycom]

Suggestion: add a burn_value field (values treated as burned may eventually be contributed to the sustainability fund) and then add a consensus rule that all transactions are required to fully balance.

[tomekpiotrowski]

I've pushed #745 to add zsf_deposit field to this PR.

[nuttycom]

This was subsumed by (and appears to have been copied into) #778