MIP-0004
Contents
MIP-0004 - TAG settings
Proposal written by NickP05
Disclaimer
I'm not the first to have this idea, but I think it's the time to write it up.
Sponsor(s)
Waiting for one
MIP summary
The hard fork consists in adding some constraints called "settings" to a specific TAG. These setting will change the TAG freedom to perform validated (by the nodes) payments.
The proposal
Hard Fork Required
Yes.
Theory Overview
Adding some settings to a TAG. The settings are constrains that limits the ability to perform transactions. The settings should be validated as a special transaction and they will be working after the block solves. Every setting has a
- reference period
- renewal period
Let's explain them together.. The reference period is a number. This number references to after how many blocks the settings values have to be reset. The renewal period is a number that refers after how many reference periods the reference period should stop to renew, and as consequence the setting should be disabled (destroyed from the ledger).
As I said before, the reference period refers to a time in which there is a variable to change. Well, that variable is defined in 2 types
- maximum_spendable --> this type of variable sets a maximum amount of MCM, as satoshi, that can be spent in the reference period into payments to the affair.
- reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the affair.
The variable I am referring to will be called spending. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.
If a transaction will be setting the spending_state below 0, the transaction should be refused by the node and not accepted in the blockchain.
At every reference period renewal, the spending_state will be reset to the original spending state stated in the setting.
Every setting is not unmovable. The settings can't be changed inside a reference period, but can be changed from a reference period to the other.
A setting change should be approved (signed) by the owner and all the co owners of the settings as a special transaction. The new setting should be identical in reference_period, renewal_period and the
variable_type as the previously setting, but it can change the spending variable. As the setting is updated, the renewal_period_state should not be forced to change.
owners and co-owners =
I mentioned before the owners and the co-owners. They all basically have the same rights. The owner is a special type of co-owner: it has the ability to renew or not renew the setting as the renewal_period_state reaches 0. The co-owners have the ability to refuse a proposed change as a setting change should be signed by all co-owners and the owner mentioned in the setting. The owner of a setting is not necessarily the TAG owner.
Technical Details
- In the Ledger Entry Struct, add an 8-byte Field "address_origin_block" containing the block height in which an address is first added to the Ledger.
- In the Block Header Struct, add an 8-byte value "recovery_total" to aggregate all recovered "lost coins" to be added to the end of the mining period as mineable coins.
- In the definitions header, add the Global definition "MAX_ADDRESS_LIFESPAN" and set it equal to 8388608 (2^23 blocks).
- Add 8-byte global variable Recovered_coins
- In the node logic, add to the Block Reward algorithm a check to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.
- If the above is true, set the mining reward for the current block to +=1 MCM.
- In the node logic, add an entry to the update() function to determine if the "recovery_total" variable is is greater than 1MCM, and if the final block reward block has been reached.
- If the above is true, debit 1 from the Recovered_coins global variable at the end of the update() routine.
- In the node logic, add an entry to the bval() routine to confirm that the Block Header "recovery_total" matches the local global Recovered_coins.
- If the above is false, the block fails validation.
- In the node logic, add an entry to the bval() routine to determine if the "recovery_total" variable is greater than 1MCM, and if the final block reward block has been reached.
- If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.
- If the above is false, the block fails validation.
- If the above is true, confirm that the mining reward reflects exactly +1 MCM over the aggregated Mining Fees for the block.
- In the node logic, add an entry to the update() function to scan the local ledger and find any ledger entry for which the current_block - address_origin_block is greater than or equal to MAX_ADDRESS_LIFESPAN.
- If the above is true, increment the global Recovered_coins variable with the Amount from the address.
- If the above is true, remove the Ledger entry for that address.