MIP-0004

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.
• 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.