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:
- 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:
- 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
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.
- Whitelisted Transparent Programs (PR, rendered)
- Bolt support (PR, rendered)
- Requires a TxID malleability fix
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)
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)
- Address retirement / expiry / revocation