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

Meros Development Fund #1

Open
kayabaNerve opened this issue Feb 18, 2020 · 3 comments
Open

Meros Development Fund #1

kayabaNerve opened this issue Feb 18, 2020 · 3 comments

Comments

@kayabaNerve
Copy link
Member

https://github.com/MerosCrypto/MIPs/blob/master/MIP-0001.md

Created in response to MerosCrypto/Meros#148, this issue represents a place for formal discussions of the MDF. The goal of this issue is not only to get it from a Draft to Finalized, yet also discuss its merits so the facts are on the table for the decision to either reject or accept it into the Meros protocol.

@kayabaNerve
Copy link
Member Author

As https://github.com/MerosCrypto/Meros/tree/Difficulty-Redo demonstrates, the handling of difficulty has undergone through a major overhaul. Keeping with MIP-0001's scaled difficulty, the difficulty now also uses an unsigned 64-bit integer. MIP-0001 will have to move over before moving out of the draft phase.

@kayabaNerve
Copy link
Member Author

Another edit required is the addition of a data field to a Recipient Form. This is so write-ups detailing why the person deserves funding can be linked, as well as provide an on-chain definition of who this Recipient is.

kayabaNerve added a commit that referenced this issue Mar 25, 2020
As #1 called for, this updates 
the Recipient Form with a memo field, as well as the difficulty 
specifications.
@kayabaNerve
Copy link
Member Author

Without any further commentary, I believe this is ready to move out of the Draft phase. The only part I'm still hesitant on are the difficulties. The reason the difficulty isn't votable is so Merit Holders can't effectively shut down the process by raising the difficulty to the ceiling. We could make use of new forms to enable people to vote on the difficulty for an upcoming period, yet I personally rather have the difficulty hard forked as needed.

It marks the change as incredibly significant, encourages regular network upgrades, implements by the people consensus (as nodes and wallets have to upgrade, it's not just Merit and Meros voting), yet shouldn't cause fragmentation (which would happen if we hard forked to decide the next recipients of the MDF). If this decision becomes problematic, we can always hard fork to an on-chain way to update them.

I'm hesitant to add benchmarks for the difficulty numbers as the spam function itself isn't finalized. Because of that, these numbers could change at any time. I'm personally in favor in moving out of the draft phase, as-is, and then changing the difficulty numbers through another MIP as needed (or through a pre-mainnet protocol change, which generally don't have MIPs assigned).

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

No branches or pull requests

1 participant