Difference between revisions of "MIP-0004"
(Created page with "= 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. == Spons...") |
|||
Line 11: | Line 11: | ||
== Hard Fork Required == | == Hard Fork Required == | ||
Yes. | Yes. | ||
+ | |||
+ | == The proposal == | ||
+ | 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 setting should be disabled. | ||
+ | |||
+ | 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 4 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 <i>affair</i>. | ||
+ | * | ||
== Technical Details == | == Technical Details == |
Revision as of 07:39, 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.
Hard Fork Required
Yes.
The proposal
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 setting should be disabled.
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 4 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.
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.