Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Planning: Grin v5.0.0 #287

Open
4 of 5 tasks
lehnberg opened this issue Apr 28, 2020 · 11 comments
Open
4 of 5 tasks

Release Planning: Grin v5.0.0 #287

lehnberg opened this issue Apr 28, 2020 · 11 comments
Assignees
Labels
development Anything related to development pm Anything related to project management task An action that needs to be taken

Comments

@lehnberg
Copy link
Collaborator

lehnberg commented Apr 28, 2020

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.



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

Milestones

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

@lehnberg lehnberg added task An action that needs to be taken development Anything related to development pm Anything related to project management labels Apr 28, 2020
@MCM-Mike
Copy link

Make it full TOR compatible:

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

@antiochp
Copy link
Member

@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
Copy link
Member

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

@antiochp
Copy link
Member

And for node -

  • allow duplicate outputs

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

@lehnberg
Copy link
Collaborator Author

@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
Copy link
Member

@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
Copy link
Member

  • 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
Copy link
Member

antiochp commented Jul 7, 2020

  • "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
Copy link
Member

@antiochp
Copy link
Member

antiochp commented Nov 25, 2020

Quick update on where we are currently with remaining items -

@antiochp
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Anything related to development pm Anything related to project management task An action that needs to be taken
Projects
None yet
Development

No branches or pull requests

5 participants