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

Agenda: Development, Mar 17 2020 #261

Closed
2 tasks
lehnberg opened this issue Mar 6, 2020 · 2 comments · Fixed by #268
Closed
2 tasks

Agenda: Development, Mar 17 2020 #261

lehnberg opened this issue Mar 6, 2020 · 2 comments · Fixed by #268
Labels
development Anything related to development meetings Anything related to meetings

Comments

@lehnberg
Copy link
Collaborator

lehnberg commented Mar 6, 2020

Solicit suggestions for agenda items for the Development meeting to be held on Tuesday Feb 18 @ 15:00 UTC in grincoin#dev channel on Keybase. Please comment to provide topics or suggestions.

Proposed agenda

  1. A yeasty reminiscence
  2. Agenda review
  3. Action point follow ups from previous meetings
  4. Basic-Auth behavior
  5. Planning
    1. Grin v4.0.0
  6. Censorship resistance for Tor-based grin tx's when Tor is blocked
  7. How to handle upgrades after 5.0.0
  8. Testing
  9. /packaging & releasing
  10. Other questions
@lehnberg lehnberg added meetings Anything related to meetings development Anything related to development labels Mar 6, 2020
@MCM-Mike
Copy link

Please add this to your general topics:
Basic-Auth behavior: As of v3.1.x if basic-auth is disabled on a Grin-Node it still accepts request with a basic-auth password. Is this behavior to be changed in the near future ?

@antiochp
Copy link
Member

antiochp commented Mar 14, 2020

Looks like NSKR/NRD locks are going to require "allow duplicate outputs" to be useful in any practical way.

We should discuss "allow duplicate outputs" as this would be a change to the consensus rules in itself. It may make sense to target this for 4.0.0 as a discrete change (vs. "relative kernels").

The rule is currently "we do not allow duplicate output commitments in the UTXO set".
Allowing duplicates would introduce various edge cases around precedence rules (plain vs. coinbase vs. immature coinbase).
We would also need to consider an adversarial scenario with millions of duplicates etc.

Is this something we want to consider?
Or do we want to continue to enforce uniqueness and work around that?

Added issue here - mimblewimble/grin#3271

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Anything related to development meetings Anything related to meetings
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants