August 12: NU4 ZIP draft Community Planning Party 🎉

Community Collaborations protocol
1

Hi all,

The August 29th deadline for NU4 ZIP drafts is fast approaching! There has already been a lot of discussion both here and in the wider ecosystem about dev fund proposals, but there are many other things that could be included in NU4, which also require ZIP drafts. Let’s give them some love!

I will be running a 2-hour NU4 ZIP draft Community Planning Party on Monday, August 12 at 10pm UK time (21:00 UTC), in the following video conference room: https://meet.google.com/vxm-jgaw-opp (not the meet.jit.si link anymore).

The goal of this meeting is to plan the creation of ZIP drafts for non-dev fund NU4 ideas (though we can branch out if there is time at the end of the meeting). The general agenda of the meeting will be:

  • Introductions
  • Overview of what a ZIP draft entails
  • Overview of the various existing ideas
  • Nomination of additional ideas
  • Technical discussion of the various ideas to establish:
    • Scoping
    • Interaction between ideas
    • Estimated work to create a ZIP draft
  • Nomination of champions for each idea
  • General discussion

To kick things off, I’ve gathered below a list of potential ideas for NU4 ZIPs that seem feasible, along with some notes about the kinds of changes each idea might require. If you would like to support / write a draft ZIP for an idea that isn’t in the list, and you can’t make the meeting, please post it in this thread! You are also welcome to put your name down for writing a ZIP draft for particular idea ahead of the meeting, which will leave more time in the meeting for discussion :smiley:

Ideas with existing or in-progress ZIP drafts

Resubmitted ZIPs

  • ZIP 210: Sapling Anchor Deduplication within Transactions
    • Requires transaction format change
  • ZIP 211: Disabling Addition of New Value to the Sprout Value Pool (PR)
  • ZIP 212: Transfer Sapling Ephemeral Secret to Recipient in Note Plaintext (PR)
    • This may be done without a consensus rule change (just a note plaintext version change), but should be synchronized with a NU.

ZIP drafts

  • Whitelisted Transparent Programs (PR, rendered)
  • Bolt support (PR, rendered)
    • Requires a TxID malleability fix

Ideas that would need ZIP drafts

Feasible

These ideas could individually be achievable for NU4, but not all of them, and not necessarily simultaneously. ZIP drafts for these would help to figure out which combinations might be achievable or complementary.

  • TxID malleability fix (#451, #2593)
    • Likely requires a block header change.
    • Likely requires a transaction format change.
    • Maybe requires a sighash change.
  • Consensus-enforced fee amounts on shielded transactions
    • Fixed equation (e.g. fixed fee-per-kiB with a floor)
    • Dynamic fee agreement (#3473)
  • Shielded transaction incentivization via dedicated block space for shielded transactions
  • User-Issued Tokens (#830) and/or Wrapped Coins
    • Requires a circuit change and transaction format change.
    • Requires defining a mechanism for white-listing tokens for wrapping.
    • For UITs, NU4 could deploy a very simple issuance scheme (e.g single issuer controlled by a multisig key).
    • For wrapped coins, requires a cross-chain migration process per-coin (type).
  • WTPs for shielded outputs (transparent programmability for shielded notes)
    • Precondition hidden inside note.
    • Auxiliary revealed in the clear upon spending (requires a transaction format change), binding to the precondition via the nullifier.
      • The binding will require either a per-WTP zero-knowledge proof, or a general circuit change.
  • Shielded timelocks (#344)
    • Would pair well with a circuit change.
    • Maybe feasible without a circuit change (and reduced privacy) via e.g. shielded WTPs.
  • Another turnstile rotation (#3667)
    • If we are doing a circuit change then we get this for free.
    • Alternatively, turnstiling without a circuit change as a policy.
  • Disable unused (or little-used) transparent opcodes
    • Note that we can’t know what opcodes are inside old P2SH addresses.
    • Could e.g. disable their use in transparent outputs that were created post-NU.
  • Using aggregate multi-signatures in a transaction (#2914)

Maybe feasible

These ideas most likely require R&D, but might be feasible if e.g. there is an existing design or implementation that can be adapted in a straightforward manner.

  • Shielded transaction incentivization via PRINCE (Privacy Incentivization for ZEC) (reddit)
    • Interesting, but needs more R&D, in particular around how the shielding bonus is implemented (to avoid e.g. widespread transaction failures).
    • A subset may be feasible.
  • Fees for long-term state preservation
    • Maybe feasible depending on how it is specified.
    • Positive interaction with consensus-enforced fees?
      • Could be implemented as a higher base fee for Sprout / transparent.
    • Roughly equivalent to the two fees in PRINCE (except the fees go to the miner here, c/f to shielding users in PRINCE).
  • Detection keys
  • Rollback protection improvements to consensus layer
  • Transaction finality
    • Ideally would dovetail with rollback protection (since transaction finality implies for the most part block finality).
  • New P2P protocol
  • New consensus-agreement protocol
  • Closer to the edge of feasibility:
    • Address retirement / expiry / revocation
      • Address archiving doesn’t require a consensus change, just a wallet performance change.
    • Address registration protocol (meaningful names / DNS for addresses)
10 Likes
2

When will a dev fund ZIP be chosen? Is it certain that one of the ZIP’s submitted in NU4 will be picked?

1 Like
3

The NU4 Feature Selection process is targeted for completion at the end of October (assuming no schedule slips).

1 Like
4

Is this going to be highly technical? (In other words, should I plan to attend?)

5

It won’t get into the weeds (there are too many ideas for that), but by the nature of the above list, there will definitely be a need for technical discussion. Championed ideas need to be sufficiently well-defined (in terms of scope and outcomes) by the end of the meeting that a ZIP draft can be written by the end of August with (at a minimum) a high-level specification (not simply motivation and rationale).

That being said, the beginning of the meeting will be focused on the functionality that each idea could provide, which may be of interest to less technical participants. But I expect that for the most part, attendees either want to help define the scope of the ZIPs, or contribute to writing them.

1 Like
6

Selecting a Dev Fund proposal is extremely important and that process is underway. However, this meeting and thread specifically excludes the Dev Fund stuff, so it is focused on all the other potential technical improvements possible in NU4.

2 Likes
7

@str4d, this is a list that’s come out of ECC brainstorming and some conversations with a few other parties.

However, I’d like to invite and encourage anyone else to submit ideas to this thread. This can include brainstormed ideas even if the technical details aren’t fleshed out, for now.

At some point (pretty soon!) we’ll need to switch from brainstorming to refining and analyzing ideas, so when we do that transition, we’ll stop accepting brainstorm ideas for NU4 (although we can put them on a wishlist for NU5).

3 Likes
8

I have added the video conference room link to the top post. See you there!

1 Like
9

We copied the list from the top post into a Google Doc and people commented on specific ideas they wanted to contribute to. If you were unable to attend the party and had a particular idea you wanted to work on, please check there first to see if others are working on it, and contact them to coordinate. If there’s an unclaimed idea, feel free to claim it!

As a reminder, there are three weeks until the draft ZIP deadline. Draft ZIPs being submitted for NU4 consideration should by that time contain basically-finished Motivation and Rationale sections, as well as a high-level specification (how will the idea be implemented). To give an example of the specification level: it should be known that the transaction will be modified to include X information, but it’s not necessary to have all the transaction format changes worked out.

3 Likes