[Proposal] Block reward % for development team.

[bitcoinsfacil]

I would like to hear opinions about establishing a % of the block reward for the continuous development of Meros. The chosen path now is a pre-mine equivalent to seven weeks of generated coins.

I don't doubt @kayabaNerve willingness to keep working but applied correctly these types of incentives make more sense for the long term. One can align the reality of the blockchain not based on past work alone but also on present work.

A pre-mine is finite, blocks are not. Miners will get payed every block because of the work they provide, I think the development team should follow the same concept. Clear rules and fair launch.

Pedro.

[kayabaNerve]

The main problems with this are:

1. A percentage based block reward leads the developers 0 room at launch. The existing premine (100k Meros at launch, with 50k every six months for a total of 350k) offers 100k MR of room at launch.

2. I won't work on this forever. I, as all humans, will eventually die. Long before that, I plan to retire. The only way to update the recipient of an indefinite block reward is a hard fork. If we aim to decentralize the hard fork recipient, it can be done via a Merit DAO or a Meros DAO. The first is giving miners control over who gets the skim; the second is giving investors.

3. Ideology. This directly takes MR from miners, where as premine takes value via inflation. While a 3.3% skim would be equivalent in practice, I prefer the ideology of indirect inflation.

In order to solve #2, I believe any solution must not be indefinite to a fixed address. It must be renewed regularly with the address which will be paid out to. This could even be on chain if the previous premine/skim recipient specifies the next premine/skim recipient. Then the hard fork would solely be to force a hand off/to disable the premine/skim.

That said, in order to solve #1, I truly believe a timelocked premine is best. It behaves the same way in effect, has a nicer ideological standpoint (in my opinion), and provides room from day 1. If the whole issue is that its finite, we can always remove the 350k cap and pay a percentage amount every six months. Sort of a hybrid solution.

[bitcoinsfacil]

1.- 100k Meros at launch is not a real room but a "hope" for those who get it. Having the coins on the wallet waiting to be used/sold just plants the seed of fear for those approaching into the coin as an investment. Inflates the blockchain with 100k Meros that won't actually be in circulation but just stored.

2. Having new developers jump in would be a dream scenario, taking your single effort into a collective one. While you are active you can act as the sole recipient distributing those rewards to those who you consider are working on a daily basis. Since you are trusted by both investors and miners. Once you retire, as you have stated, that can be solved in multiple ways even removing it completely.

3. Meros should be usable but scarce. There is no Meros taken from miners. With clear rules, in the beginning, every miner can choose whether to mine or not. Normally miners decide based on profitability and that will depend on how well Meros can incentivize demand while restricting the supply.

Thanks for engaging on this discussion @kayabaNerve

[kayabaNerve]

1. Developers interested in joining the project will feel otherwise.
2. My retirement shouldn't require a hard fork.
3. In my opinion, ideologically, any part of the block reward not given to miners is taken from the miners.

[bitcoinsfacil]

1. With a steady source of Meros coming from the blockchain they won't fear the development fund ends up empty. Once it is empty no one works.
2. This point is futurology. long term, short term, retirement, daos. All into the future of a newborn.
3. How can something be yours if you still don't own it?

Clear rules from the start:
% for miners + % for development = Block reward for those who work

[kayabaNerve]

1. Sure, they won't become empty, yet we'll have to wait months for a meaningful amount to work with.
2. Any solution which requires a hard fork on retirement won't be included.

[nothingismagick]

In the original comment from @bitcoinsfacil:

One can align the reality of the blockchain not based on past work alone but also on present work.

I don't see that reflected in your proposal. It smells a little bit like "before the mining began, no work of value was undertaken" - which is patently untrue.

The only feasible way I can see this working without turning into some kind of rigged buddy-system or risky meritocracy is by implementing something akin to https://sourcecred.io/ - which tracks all contributions and awards a percentage of a daily, weekly, monthly, quarterly tokens. This guarantees fairness and transparency - and believe it or not, is an alternative to faceless bounties.

In fact, it sort of turns the notion of "contributions" on its head - to the point where even this conversation would be considered a contribution.

At the moment it will require a bit of bookkeeping to manage a sourcecred instance, but I can attest to the fact that it increases participation. It also does a decent job of rewarding "prior" work in a kind of "intellectual staking" - which might resolve the concerns that @kayabaNerve brought up.

[kayabaNerve]

SourceCred could offer good guidelines if we went the centralized route. Any decentralized route eliminates it.

Despite SourceCred claiming decentralization, and somewhat meeting that term, it isn't decentralized for our purposes. Even if we embedded our own version in every node, it'd need a set of repos to track on a centralized website unless we embed Git management of Meros into Meros and add a DAO to accept commits.

Beyond that, contributions are defined as much more than code/repository interactions. They're defined as marketing, informing, partnering, coding, developing, and sharing. Going based off SouceCred (or their theory) removes several of those classes unless we create empty PRs that act as representations.

That said, I do like the idea of focusing on completed work over promised work.

[kayabaNerve]

https://github.com/MerosCrypto/MIPs/blob/master/MIP-0001.md is a proposal written specifically to solve this issue.

[bitcoinsfacil]

I don't see that reflected in your proposal. It smells a little bit like "before the mining began, no work of value was undertaken" - which is patently untrue.

@nothingismagick not at all, it might have come out like that but not the intention. I am actively pushing towards having those who work on Meros get paid by Meros. Past, present, and future included.

Now that the push is getting discussed with a proper proposal format I will close this, thanks @kayabaNerve for the space.

[kayabaNerve]

Actually, while MIP 0001 should have its own issue for discussion, I'd like to keep this issue open until MIP 0001 is either accepted or rejected.

[bitcoinsfacil]

But I think we could open up an issue for that one then right? This one might not entirely reflect what MIP 0001 tries to achieve @kayabaNerve

[kayabaNerve]

Please note I just created an issue on the MIPs repository for discussion specific to MIP-0001, rather than this issue as a whole. Until the existing solution is reaffirmed, or a new solution is accepted, this issue should remain.

[kayabaNerve]

This shouldn't have been closed, as it's not yet resolved. Planned, and effectively certain, resolution will be MIP-0001. That said, it has yet to be integrated into the Protocol docs nor implemented into the node. This still serves as a tracking issue.