Difference between revisions of "MIP-0004"
Line 8: | Line 8: | ||
== MIP summary == | == 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 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 == | == Hard Fork Required == | ||
Yes. | Yes. | ||
− | == | + | == 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 | 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 | * reference period |
Revision as of 07:57, 23 November 2020
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.
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 stated in the setting
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.