[ZIP 227, ZIP 230, ZIP 246] Addition of burn fields into the Action Group

[vivek-arte]

Creating a PR for this that targets the branch which adds ZIP 246 (aka #987)

[str4d]

The stated rationale (which has not yet been documented in ZIP 226) is:

to allow parties to be able to burn Assets as well, otherwise the burning ability remains only with the bundler.

The privacy implication of this change is that per-ActionGroup burns are visible on chain. Compare this to transfers: the per-ActionGroup transfers are visible to the bundler, but because bindingSig is only at the top-level Bundle, the on-chain transaction does not reveal how any kind of asset moved around between ActionGroups (or even what assets were involved).

An alternative that would preserve privacy while providing the same functionality would be (suggested by @daira during ZIP Sync):

• Have each ActionGroup include a hiding homomorphic commitment to the asset balances burned.
• Change the top-level bindingSig calculation to include these commitments in some way.
  • This might look something like "use the commitments in bindingSig, and then have additional per-asset binding signatures or openings alongside vAssetBurn for each burnt asset".

However, this does add complexity, and for a change that is already being proposed by qedit well beyond the semantic stability point for the ZSA ZIPs, it might not be reasonable (whereas altering the v6 transaction format in this way is still within the bounds of reasonability).

[daira]

Just to be clear, I suggested this mainly to document the fact that it was possible to achieve the functionality without any privacy issue, not because I think it's worth the complexity.

[str4d]

@vivek-arte said:

any mismatch that requires altering burns

Did you have a different scenario in mind?

The scenario I had in mind is:

• AlphaBucks, BravoBucks, and CharlieBucks are all assets bridged in from some other chain.
• Alice creates an ActionGroup selling AlphaBucks and buying BravoBucks.
• Bob creates an ActionGroup selling BravoBucks and buying CharlieBucks.
• The bundler matches these two ActionGroups by creating a transaction in cooperation with the bridge that:
  • Burns the AlphaBucks (thus enabling the AlphaBucks to be traded for CharlieBucks on the other side of the bridge).
  • Issues the CharlieBucks (that were received in the trade on the other side of the bridge).
  • Maybe has their own ActionGroup that does other matching things as necessary.

This seems like a common case if the bundler is also a liquidity provider on the other chain.

[str4d]

Regarding the need for the bundler to contribute their own ActionGroup, we now know qedit were assuming this would be the case:

For the subsequent Swaps addition, we already expect the bundler to create their own Action Group in order to collect any "matching fees", so this is not a cost that is not already part of the Swaps mechanism.

I was not assuming this. It would be entirely consistent for the bundler to instead require that the ActionGroups it bundles contain fee outputs to the bundler's address. This would increase the number of Actions in the bundled ActionGroups (but that may already be the case if the ActionGroup contributors are spending multiple notes, for example, and thus not distinguishable) without increasing the number of ActionGroups.

[str4d]

any mismatch that requires altering burns

An example is when someone creates an Action Group with burn fields corresponding to Assets they don’t have. If the bundler wants to accept such an Action Group by adding the necessary Assets to the transaction themselves, they are free to do so (though I don't see why they would?).

@nuttycom notes that the ability for an ActionGroup to require that an asset amount gets burned that their own ActionGroup does not provide, can be used to implement locking mechanisms:

• Alice provides an ActionGroup that sells AlphaBucks and buys BravoBucks, and requires burning one ZetaLock.
• Bob provides an ActionGroup that sells BravoBucks and buys AlphaBucks, and also "sells" one ZetaLock, and requires burning one YottaLock.
• Charlie (or the bundler) provides an ActionGroup providing one YottaLock.

Similarly, Alice and Bob could use this to create ActionGroups that can only be satisfied by each other. They could also do this by including within the transfers a requirement to receive a specific lock token, rather than to burn the token, so the mutual case has less need for burn functionality. But the general "acquire a lock from an issuer, burn the lock upon use" still might be useful.

[str4d]

So to summarise:

• This change adds functionality: a user contributing the ActionGroup can require that some other asset is burned (whether or not it is present in their own ActionGroup's Actions).
• This change has a privacy downside relative to the existing change specified in ZIP 226.
• The privacy downside could be fixed, but it would add complexity to ZIP 226 long after it was supposed to be semantically stable.

[daira]

I don't personally think the privacy downside is a big deal. You can avoid it in most cases by communicating the amounts to be burnt to the bundler and having only the single ActionGroup added by the bundler include the burns. This works provided that the ActionGroup contributors do not require the burns as a condition of their participation. But the protocol with the burns only at the top-level does not support such requirements anyway.

To dot a i and cross a t: in my suggestion where commitments are used for the amount to be burnt in each ActionGroup, the difference between opening a commitment and using a binding signature would be that the latter does not reveal the sum of commitment randomness. This is used for actions to avoid the sum from being replayed, if the transaction is revealed to an adversary. Note that binding signatures are a little more expensive to validate.

I think there is sufficient utility to make this change. I don't especially object to using commitments to hide the individual burn amounts but don't think that it's needed.

[str4d]

Consensus from the ZIP Editors (@str4d, @nuttycom, @conradoplg, @arya2) (@daira also expresses agreement):

• We're happy for the change to the transaction format to go in.
• We are open to qedit addressing the privacy problem and proposing a subsequent change (to all of the specs, and all of the implementations) prior to the selection of the NU7 testnet activation height.
  • Fixing it after NU7 would require another transaction format change, and avoiding this is the entire point of specifying the Atomic Swap-related changes up-front. So it would not be fixed in the same NU that deploys Atomic Swaps, and thus would likely never get fixed (or at least would only be fixed whenever a v7 tx format gets specified).

[PaulLaux]

Critical discussion, indeed.
The main motivation for this change was to allow the swap sides the ability to burn publicly as per the original OrchardZSA design.
It feels like a more natural extension to OrchardZSA than simply forbidding it and moving it to the TX level instead of the action group level.

However, as the zip editors mentioned, swapping and burning as part of a bridge operation might create a privacy issue.

In the mentioned scenario, the bundler/matcher has a choice: either the burn happens in the context of the same swap transaction and is revealed to the public, or instead of burning, the matcher directs (transfers using actions) the assets privately to its own account and burns them publicly in a subsequent transaction, disconnecting burnt assets from the swap.

The two-step process aligns with the mirror scenario of publicly issuing to self and privately distributing in a subsequent transaction.

We are open to both keeping the semantic as-is (burns inside action groups) and we can suggest a way to hide the burn.

As mentioned, it is not trivial to hide the burns and we belive that the two step process is enouth to address the privacy concern.

The decision whether to hide the burns is up to the zip editors (qedit will make the design and changes if needed). Our recomendation is to keep the current semantic of burns inside action groups.