MIP: 0001
Title: Meros Development Fund
Author(s): Luke Parker (@kayabaNerve), Lee Bousfield (@PlasmaPower)
Category: Hard Fork
Created: February 11, 2020
Status: Draft
This proposal details a decentralized fund in order to fund Meros's development ad infinitum. Every six months, a vote is held in order to determine who should receive the fund. Voters assign a score of 1 to 100 for potential recipients they believe deserve funding. The voter's assigned scores must total 100. The recipient's actual score is the weighted median of their assigned scores, where the weight is the amount of MR behind each assigned score. The recipients' scores are then normalized to be out of 100. This normalized score represents the percentage of the fund the recipient will receive. The fund's payout is equivalent to 5% of the average Block reward, including rewards which were never paid out due to a lack of Verifications, since the previous voting period ended (exclusive) to when the current voting period starts (exclusive). A lump sum is paid out every 1008 Blocks (every week).
Meros already has a premine specified as 352,800 MR, paid out over 6 moments. The first would be when the network launches, with a value of 100,800 MR. Then, every six months, an additional 50,400 MR would be paid out until the full sum was distributed. These payments would be to a predefined address, belonging to @kayabaNerve, and would be further distributed as he sees fit. Unfortunately, the problems with this are two-fold. The first is its complete centralization; the second is the fact this premine is only distributed for 2.5 years and could only feasibly last a maximum of 5 years.
Recently, @bitcoinsfacil pointed out the problem with the premine terminating after just a few years. This caused alternative solutions to be discussed, which all boiled down to four core aspects:
- Designation. Who receives the fund?
- Frequency. How often is the fund delivered?
- Amount. How large is the fund?
- Termination. When does the fund cease to exist?
@bitcoinsfacil's post primarily pointed out a problem with the fund ceasing. The continued discussion also pointed out a problem with the premine being delivered in such large lump sums, which can heavily affect the price. The designation being static, and therefore centralized, has also been a sticking point since it was decided.
Due to all these factors, and being able to come up with a better solution, we designed a solution which ensures Meros's future is completely decentralized, and has funds delivered often enough to not significantly affect the price (yet not often enough to cause pointless bloat).
The period number starts at -1. Whenever the height equals 1, or (height % (4320 * 6)) - (4320 * 5) equals 1, a new voting period starts. This causes a voting period to start as soon as the chain is launched, as well as a month before every six-month mark. The start of a voting period increments the period number, which is then assigned to the new period, and sets the recipient number to 0. The period amount is 5% of the average Block reward since the last period ended. If the period number is 0, the period amount is 10% of the average Block reward since the chain started. Blocks without a reward do not count towards the average in any Form.
Once a voting period starts, two new data objects can be archived in Blocks. This is thanks to adding a new property, mdfForms. BlockBody serialization is modified to include the 4-byte amount of Meros Development Fund Forms and each form (each prefixed by the same prefix used in the contents Merkle) immediately after the BlockBody's Elements, yet before its signature. The amount of forms is always present in every BlockBody message, despite only being valid with a non-zero value during certain heights.
4320 Blocks after a voting period starts, it ends. Every key has their weight defined by the amount of MR they have, calculated by summing the key's outputs from finalized Claim/Sends which don't have any on-chain spenders. Every recipient has a weighted median created to determine their score, where everyone who voted yet didn't vote a score for that recipient automatically votes 0. Every result of the weighted medians is normalized to 100 via:
total = sum(scores)
for recipient in scores:
scores[recipient] = scores[recipient] * 100 / total
If the normalized scores don't sum to 100, the recipients have their score incremented until they do (via iterating from highest scoring to lowest scoring recipients, incrementing by 1 on each pass, and using the higher key to break ties).
The normalized score represents what percent of the fund that recipient receives. Whenever it's been at least 10 Blocks since the last voting period ended, and the height % 1008 equals 1, the period amount, multiplied by 1008, is distributed to all the recipients via a Send transaction which uses a hash of the Block's hash xor'd with "MEROS_DEVELOPMENT_FUND", after it's right padded to meet the hash length.
Every Form has the following fields:
- hash: A hash used for the signature and difficulty.
- period: Voting period this Form is designated for.
- signature: Ed25519 Signature created by signing the hash.
- proof: Work that proves this isn't spam.
Recipient Forms are used to declare a key as an eligible recipient for this voting period, and have the following additional fields:
- key: Ed25519 key.
- maximum: Maximum percentage which can be received.
- memo: A memo, up to 256 bytes long, which is enforced a single byte provided for the length in the serialization.
If the maximum is set to 0, there is no maximum. The maximum must be less than, or equal to, 99.
Recipient Forms use a prefix of "\xFE" in the contents Merkle. Their hashes are defined as Blake2b-256("\xFE" + period + key + maximum + memo), where period takes up 2 bytes, key takes up 32 bytes, maximum takes up 1 byte, and memo is of a variable length.
The proof is only valid if:
factor = (104 + memo.length) / 104
spam(hash, proof, 10000 * factor)
When a Recipient Form is archived on the Blockchain, the recipient number is incremented and then assigned to the newly eligible recipient.
Recipient has a variable message length; the 2-byte period number, the 32-byte Ed25519 key, 1-byte maximum, the 1-byte memo length (where the length is the byte's value plus one), the variable-length memo, the 64-byte Ed25519 signature, and the 4-byte proof.
Vote Forms are used to vote for who should actually receive the Fund for until the next voting period, and have the following additional fields:
- keys: Ed25519 keys.
- votes: Recipient number and assigned score pairs.
The sum of all votes must equal 100. All votes must be less than or equal to the recipient's maximum. If a vote was for recipient 0, the vote is for no one to receive those funds. Whatever percent of the funds recipient 0 wins will not be minted.
Vote Forms use a prefix of "\xFD" in the contents Merkle. Their hashes are defined as Blake2b-256("\xFD" + period + keys.length + key[0] + ... + key[n] + votes.length + votes[0] + ... + votes[n]), where period takes up 2 bytes, keys.length takes up 1 byte, every key takes up 32 bytes, votes.length takes up 1 byte, and every vote takes up 5 bytes (the 4-byte recipient number and 1-byte score). If multiple keys were specified, the same MuSig process as used for Sends is used to create the signature.
The proof is only valid if:
factor = (73 + (32 * amount of keys) + (5 * amount of votes)) / 110
spam(hash, proof, 60 * factor)
Vote Forms which use a key which already has a Vote Form for the same period archived cannot be archived.
Vote has a variable message length; the 2-byte period number, the 1-byte amount of Ed25519 keys, the Ed25519 keys (each 32-bytes), 2-byte amount of votes, the votes (each a 4-byte recipient ID and a 1-byte score), the 64-byte Ed25519 signature, and the 4-byte proof.
While not technically incompatible with the premine, this solution is meant to replace the premine completely. When presented with a competent decentralized solution, centralized solutions should be dismantled.
The weighted median algorithm, combined with automatic zeroes for whoever isn't voted for, requires the majority of MR to agree a recipient should receive part of the development fund. Controlling the vote, even to just decide who's present in the list of recipients, requires 51%.
That said, it is extremely easy to buy votes right before the voting period closes, just to sell them later. Multiple theories to handle this have been thought of, from MR weight decaying as it's transferred to a minimum coin age. The first isn't effective as coins on an exchange are frequently stored on a cold wallet. The second isn't effective as it only lets people rich enough to let coins sit around vote.
If we wanted to move past one coin, one vote, to one person, one vote, we'd need to centralize the election. This could be via a KYC process with government IDs, or it could be a group of people approving other people as time goes on. The centralization with the second is solely that there must be a hard coded initial person. That said, the second is extremely weak as you can't require IDs, and therefore can't detect when one person is pretending to be three people (Sybil attack). Neither of these are therefore viable options.
Thanks to using a 4-byte integer for the recipient ID, and reserving 0, only 4294967295 recipients can exist. That makes it extremely important to limit the amount of recipients entered via a competent spam function. Every Vote can also add 8.6 KB to the chain, so that also requires a competent spam function. In order to not require 4 GB of RAM to vote, RandomX was not used. The existing Argon2d (used for Sends and Datas) OR a VDF should be used. That said, the latter is experimental while already having FPGAs available, hence why Argon2d was chosen.
Test vectors will be included once the protocol finalizes.
Copyright and related rights waived via CC0.