Proposal Started - May 1st 2024
Proposal Released - June 5th 2024
The time for the 'one game' is over, let's move on to something better!
‘minting is a privilege, not a right’
In order to understand the reasoning for this proposal, we must first examine the multitude of concepts and actions that lead up to this point. Since Qortal’s Genesis, and concepts leading up to Genesis, the idea for Qortal Minting, was such that in order to become a minter, one must first obtain a ‘sponsorship key’ from another minter of level 5 or higher, or a Qortal Founder.
It was always known that eventually there would be modifications necessary to such a concept, as obviously there is ‘one game’ that can be played, ‘self-sponsorship’. Self-sponsorship is the idea that instead of utilizing the sponsorship concept as it was meant to be, and creating a NEW minter into the Qortal ecosystem, selfish, greedy, or otherwise immoral users would ‘self-sponsor’, creating a new minting account that they themselves controlled.
At Genesis, the decision was also made to allow those from the QORA project (which had been considered ‘dead’ since years prior) to ‘transition’ to Qortal in multiple ways. One of those ways was that if they had been ‘forging’ QORA blocks during the period of time QORA was considered ‘dead’, they could be credited with a ‘pre-enabled level’ on Qortal based on those forged QORA blocks. This concept was created so that the Qortal founders would not be the ONLY people who were able to create new minters, and thus be a more decentralized start to the Qortal Minting consensus.
However, out of the best intentions, allowing the QORA community to start with higher levels ended up causing a huge amount of damage to the project, as those who were rescued from the dead QORA project (many of them anyway…) became the first group of big self-sponsors. Greed and other selfish desires drove them to become self-sponsors immediately, thus inflicting the ‘one game’ upon the Qortal community much earlier than expected.
As a result, the Qortal Development Group took various steps, including the introduction of the ‘self-sponsorship algorithm’ to find and remove minting rights from self-sponsored accounts. Also, the addition of the ‘MemPoW’ algorithm into the consensus of Qortal, to keep it so that only a limited number of minting keys can be assigned per physical machine. Both of these modifications helped, but overall the self-sponsorship continued.
A second run of the self-sponsorship algorithm more recently, also removed a good number of self-sponsored and self-sponsoring accounts’ minting rights, however, complete removal of the self-sponsorship of Qortal, obviously requires a more in-depth concept. That concept, is the one being presented here. We are calling it ‘mintership’, as a combination and play on words between ‘mentorship’ and ‘minting’. We firmly believe that this is the ONLY WAY that the self-sponsorship concerns of Qortal will be ELIMINATED COMPLETELY.
• Minting will no longer be started with ‘sponsorship’. Instead, new minters will need a new type of group_approval, from ‘mintership-enabled’ groups. Mintership-enabled groups and the admins therein, are the only ones that are able to invite minters to the ‘minter’ group.
• The ‘minter’ group is essentially ‘enabling minting’. Minters that are not part of the minter group will fail minter signature validation checks, and will not be given credit for blocks minted, nor given QORT minting rewards. The signatures submitted from minters that are not part of the minter group, will be disregarded by consensus.
• ALL minters will need to obtain approval, existing and new minters included. The exact means for existing minters to obtain this approval is still being determined, however, it will likely involve a combination of on-chain data and ‘vouching’ either for themselves or getting vouched for by another. On-Chain data will play a crucial role. Those with obvious associations with previous self-sponsors, or without any real on-chain data to compare against, will have a more difficult time obtaining approval.
• Approval will consist of a certain number of signatures, with a new GROUP_APPROVAL transaction type. This type will, instead of requiring a certain percentage of group admin signatures for a group_approval, will instead require a certain number of signatures by a mintership-enabled group. This signature process will be very similar to that of the dev-admins, wherein only the admins of mintership-enabled groups will be considered. A certain NUMBER of signatures, instead of a percentage, will be utilized to approve new minters.
• Once approved, a group invite to the minter group will be sent to the would-be minter’s account. Once accepted and confirmed, the new account will become part of the minter group, and their minting signatures will be validated just like current minting signatures.
• Utilizing this new group-based method, will remove the requirement of a ‘temporary key’ (previously known as ‘sponsorship key’) entirely. New minters will simply need to mint the normal required number of blocks in order to become level 1. None of the other concepts of Qortal Minting will be changed, this proposal targets specifically the sponsorship concept, in order to completely remove self-sponsorship.
• Accounts that are not in the private minting group will fail validation upon submission of a minting signature. This means that if an existing minter is NOT part of the minting group, they will not be able to mint. This also means that existing minters will also be able to keep their current blocksMinted, and every other part of their existing minting account. No modifications outside of whether a minting signature is accepted or not based on the account being part of the minting group, will be required.
• ‘Sponsorship’ is no longer a thing. Only mintership-enabled groups will be able to create new minters, and enable existing minters.
• Mintership groups will become the second most important in terms of groups on Qortal. The dev-group and mintership groups will become very important. They will also be given further rewards (see ‘founder rewards modification’ proposal for details) for their active contribution toward the platform. This is the original ideal of the platform, to reward those who CONTRIBUTE.
• The admins of the mintership groups, are the ones who can submit approvals for the transactions created by the group. These will include both enabling a new minter, and allowing an existing minter to continue minting. These admins will become very important to Qortal.
• Initially, there will be only ONE mintership-enabled group. We will start this way for simplicity. However, as time goes on, there will be a way to ADD mintership ability to other groups. This way, it will not always be in the hands of a single group. However, even with just a single group initially, any number of users can be added to the group, so even with one it’s not really a limitation.
• In order to become admin of a mintership group, the existing admins of the group must do a group_approval (just like the dev-admins are now) and a certain percentage threshold must be met in order for the transaction to be processed, and a new mintership group admin to be added. Mintership admins will be the ones who are able to determine the status of minters on the network.
• Following the same principles as the dev-group now, (and the admins therein being the ones that sign the auto-update transactions,) we will apply the principles to mintership groups as well, and apply their group_approval to adding and removing minting ability, and adding and removing mintership admins. To add a new admin, x% approval of the existing admins is required. To add a new minter, a certain set number of signatures is required (most likely starting at 3).
A forum for communications between mintership groups and minters or new users wishing to become minters, will be created and made available so that the required communication can take place in a fashion that will not be ephemeral (i.e. Q-Chat).
The forum will retain the information for others to review and add to in a neat and orderly fashion (with threads and comments therein, topics, etc.) and a single easy location for all mintership and minting related information. The mintership forum will be built as soon as possible, crowetic is planning on attempting a simple version to be available prior to the concepts of the proposal going live.
Prior to implementing this concept, multiple things will need to take place. The creation of the first ‘mintership’ group, a plan for the process, time-frame, and concept for allowing existing minters to become approved, etc.
The way this should be able to take place as quickly as possible, should likely follow a scenario as described below:
• The initial mintership group will be determined and activated (after development and testing of the means with which to provide said activation.) This will provide the means by which new and existing minters will be granted the gift of becoming active.
• An existing group may be turned into the original mintership group, this determination will need to be made. However, it seems very likely that an existing group will be utilized, this will ease the transition, and this group is one that has many known solid members of the community, and already puts in effort similar to what would be needed from the mintership group. So it seems like a logical starting point for the concept.
• Initial Mintership admins will be determined by communication within the group, and figuring out who amongst the group (or newly added people upon request/approval therein) would be best suited to be a mintership admin. The mintership admins must be ACTIVE and READY to be able to sign the group_approvals required for the concept. This means the mintership admins must be those who are continually active in the community, and preferably using Qortal on a daily basis. After implementation of the concept, mintership group admins will be determined by the existing mintership group admins, or dev-group admins by way of group_approval version 1. (The fail-safe of using dev-admins is in place just in case. It may be possible to make it so that the dev-group admin approval is only possible after an attempted and failed mintership admin approval. TBD.)
• Active minters will be part of a private group that is only able to allow invites by way of group_approval (of type 2 – with a set number of signatures required, most likely starting with 3) from the mintership admins. ALL minters must be part of the minting group in order for their minting signatures to be counted. Any minter who is NOT part of the minter group will NOT be able to mint.
• A period of 3 months (or another time-frame to be determined based on comments, etc…) will be provided by which existing minters may obtain approval.
• Any minters that do NOT obtain approval during this period, may do so any time. There is no limit to the approval of a minter, it is simply a new requirement in order for minting signatures to pass validation. There is also no need to be concerned about being approved within the initial period. However, any minters that are NOT in the group, will not be rewarded in QORT nor blocksMinted.
• In order to make this transition as easy as possible, on-chain data will be utilized in determination by the mintership and developer groups to decide upon which minters will be given ‘pre-approval’ without the requirement of communication to the mintership group. There will be many minters who will be allowed to be in the minter group without requirement of specific approval. (Determination as to whether the ability for the developers to add members to a newly created group by way of a hard fork as opposed to requiring those members to accept a group_invite will be made as well, and if it is possible, will take place upon minter group creation after above-mentioned discussion and determination of which accounts are deemed to be ‘legitimate’.)
• Basically… minters who are reviewed and determined to be legitimate minters, based on existing chain data, will be added to the minter group. They will be added either by development upon implementation of the proposal, by way of a hard fork that adds certain accounts to the minter group, or, if that is not possible, will be sent a group_invite that they must then ACCEPT in order to be part of the group.
• It may make more sense to simply force required acceptance to be made as opposed to utilizing a hardfork to add accounts to the minter group, but this decision will be made upon review of commentary from the community on this proposal.
• Minters who are NOT added/invited to the minter group based on the on-chain data, will then need to obtain the invitation in the ‘new normal’ fashion, by requesting it from the mintership group in the mintership forum. Exact details on this request, requirements, etc… will be determined over time. Communication in comments of this proposal will be taken into consideration by the Qortal Development Group.
• Approval to mint requires (tentatively) 3 (three) signatures from mintership-admins. (Dev-group admins may retain a ‘fail-safe’ option by including the dev-group and dev-admins in the mintership group decisions. This would be in case the mintership group for whatever reason doesn’t have enough active admins to approve new/existing minters. Dev-group admins will then be able to add new minters as well. With the same group_approval 2 and specific number of signatures required). If this fail-safe is implemented, it may start as simply allowing dev-admins to approve new minters (for ease of development) but then should transition to a method wherein the dev-admins may only approve a new minter if the mintership group has already submitted for an approval, but was unable to obtain the required signatures.
• Minting officially becomes a privilege, as it should be, and becomes something treated with the respect it deserves. It has been apparent for too long that minting in its current state is not treated with the respect it deserves.
• Minters in the minter group will be able to continue minting as they were before, no underlying changes to the way minting functions are required, the same self-share private key will be utilized to sign blocks, and be rewarded for minting. This makes the transition very simple. The only additional requirement is to be part of the minting group.
• Minters that are NOT part of the minting group, will still ‘mint’, but will not be credited, as the validation of the minting signatures will invalidate any signatures submitted by any account outside of the minting group.
• During the pre-mintership period, all minters who wish to be in the minter group from the start, will need to be approved. If they are not part of the pre-approved minters that came from analysis of on-chain data, they will have to be approved by the mintership group admin approval process just like any new minter.
• The pre-mintership time-frame is there merely to ensure there are enough minters in the group to ensure chain functionality. The pre-mintership time-frame is NOT the only time a minter can be added to the group.
• New minters AND existing minters can be added to the group at any time, by a group_approval type 2 from the mintership group admins, or as a fail-safe the dev-admins.
The plan as of May 31 2024 is to get this overall idea/proposal put out so that the community can comment and vote on it. At the same time, we will be planning the release and development.
Upon the review and any necessary changes to the proposal, we will then have most of the development concepts planned, and the initial roll-out getting ready to go.
In order to do this, we will need to prepare as much as possible as if the proposal will pass, and plan the best methods to implement the changes.
Leveraging concepts that already exist in the Qortal Core, will make this process a lot faster, and get to the end result a lot more quickly. This is why leverage of the Qortal groups makes the most sense. If built as written above, only a couple new additions will be required, the groups specific for minting and mintership, validation checks for minter group signatures upon minting signature validation, and ‘group_approval type 2’ that checks for a set NUMBER of signatures instead of a set PERCENTAGE to allow for 3 signatures from mintership (or in the fail-safe case, dev-group) admins, to invite an account to the minter group.
New Public Qortal Testnet
Implementing such a dramatic modification to the base level functionality of Qortal, will take some significant effort and logic. In order to effectively release a change like this, it will require pre-planned execution of multiple things. Most likely a new public testnet will be created to test this (and other) concepts thoroughly in a more realistic environment. Details regarding the new public testnet will be provided upon its creation.
Final Information
This proposal is subject to modification based on Qortal user comments published and discussed on the proposal website. By no means is this a ‘final version’. Development communciations must take place in order to discover the best means of implementation and development and testing must take place prior to the build.
This concept is to REMOVE ENTIRELY the ability to SELF-SPONSOR. Thus eliminating the ONE GAME that can be played upon Qortal’s consensus. This will make it so that only LEGIT minters will be rewarded for ACTUALLY supporting the network.
This proposal goes hand-in-hand with the FOUNDER REWARDS MODIFICATION PROPOSAL that can be found HERE. This includes the removal of founder rewards, and replacement with dev-admin and mintership-admin rewards.
This way mintership admins who must be active and stay vigilant in selecting those worthy of the honor of becoming a Qortal minter, will be rewarded for their ACTUAL EFFORTS. This also ensures that the dev-admins who keep the auto-updates going on the platform, are rewarded for their actual efforts and efforts in staying active and developing the Qortal platform.
If the founder rewards modification proposal is not completed by the time this proposal is posted, it will be completed and published shortly after. PDF versions of both proposals will be available on Q-Share.