Release Planning: Grin v5.0.0

[lehnberg]

Planning issue for version 5.0.0 of grin and grin-wallet, which is to support the scheduled network-wide upgrade occurring at block 1,048,320, around Jan 15, 2021.

---

• v5.0.0-beta.1 (node) Release notes: v5.0.0 Release Notes grin#3506

---

Milestones

• Oct 13 2020: Scope freeze
• Nov 24 2020: Beta release
• Dec 08 2020: Testnet fork
• Dec 15 2020: Release candidate 1
• Jan 05 2021: Final release

Discussion

Planning discussion can be had asynchronously on this issue, or in development teams on keybase.

Definitions

P1 - Critical
P2 - Important
P3 - Fix if time

📝: awaiting specification
🛠: in progress
✅: merged
🔍: awaiting review

---

Project board

• https://github.com/orgs/mimblewimble/projects/1

Milestones

• Node: https://github.com/mimblewimble/grin/milestone/19
• Wallet: https://github.com/mimblewimble/grin-wallet/milestone/9

Finalized scope

#	Priority	Team	Description	Owner	Reference	Status
1	P1	Node	Fix DAA	RFC: @tromp impl: @tromp	mimblewimble/grin-rfcs#61 mimblewimble/grin#3473	✅
2	P1	Node	Fix fees	RFC: @tromp impl: @tromp	mimblewimble/grin-rfcs#63 mimblewimble/grin#3369	✅
3	P1	Node	Bump header version + any pow changes	@tromp	mimblewimble/grin#3472	✅
4	P2	Wallet	Late locking	@yeastplume & @jaspervdm	mimblewimble/grin-wallet#524	✅
5	P2	Wallet	Deprecate HTTPS	RFC: @j01tz impl: @jaspervdm	mimblewimble/grin-rfcs#54 mimblewimble/grin-wallet#523	✅
6	P3	Node	(Partial) PIBD	RFC: @jaspervdm impl: @jaspervdm & @antiochp	mimblewimble/grin-rfcs#68 mimblewimble/grin#3471 mimblewimble/grin#3470	✅
7	P3	Node	Disable v1 API	@quentinlesceller	mimblewimble/grin-rfcs#71	✅

Out of scope

• Safe cancel: [WIP] Safe cancel grin-rfcs#71
• Tor only nodes
• secp256k1 fork updates
  ...and more

[MCM-Mike]

Make it full TOR compatible:

• run Grin-Node in TOR only mode
• make it ready to connect to other Tor Grin-Nodes
  (tbd)

[antiochp]

@yeastplume @j01tz what's the context for (1) - is this "multi-party txs" in the sense of payment channels etc. or referring to something else?

[antiochp]

I'd like to propose adding the following for wallet -

• "mostly" lock free transactions. https://forum.grin.mw/t/mostly-lock-free-transactions/7313

[antiochp]

And for node -

• allow duplicate outputs

This one is presumably contingent on us deciding we want to do this.

[lehnberg]

@DavidBurkett:

I think we should revisit block weight anyway before the final hardfork. I have some concerns with the current approach that are worth discussing. I'll add it to my list of forum posts I need to write

[putting as placeholder for myself to remember]

[antiochp]

@DavidBurkett:

I think we should revisit block weight anyway before the final hardfork. I have some concerns with the current approach that are worth discussing. I'll add it to my list of forum posts I need to write

[putting as placeholder for myself to remember]

Issue for "max block weight" discussion (related to above): mimblewimble/grin#3368

Fee discussion also (loosely) related to block weight: mimblewimble/grin#3369

[yeastplume]

• Consolidation of wallet commands / API functions (e.g no need for separate 'receive', 'finalize' etc commands) Doesn't have to be 5.0.0, but a 4.1.0 should contain the 'final' version of all wallet commands so everyone has time to adjust before 5.0.0
• Method of Slatepack address cycling
• More optimised SQL backend option for scalability needs (does not need any particular HF or major/minor release)
• (Nebulous thought) any changes/standards that might be desirable for an offline transaction relaying solution? Highly dependent on what direction we decide to take with this.

[antiochp]

• "coinbase inputs" (we should not need to specify output features when spending). Related to/overlaps with "duplicate outputs" in terms of spending precedence rules.

Note: This is not the same as "coinbase outputs as transaction outputs". This is related to how we specify outputs to spend via inputs in txs and blocks.

[quentinlesceller]

• Update our fork of https://github.com/mimblewimble/rust-secp256k1-zkp with latest optimisation such as Cut verification/signing/proofs etc. time by half for 64bit machines rust-secp256k1-zkp#71 (does not need any particular HF or major/minor release)