search

MerosCrypto / MIPs

Meros Improvement Proposals.
1 stars 0 forks source link

Meros Development Fund #1

Open kayabaNerve opened 4 years ago

kayabaNerve commented 4 years ago

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

Created in response to https://github.com/MerosCrypto/Meros/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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).