Difference between revisions of "MIP-0004"

From Mochimo Wiki
Jump to: navigation, search
 
Line 39: Line 39:
 
=== owners and co-owners ===
 
=== 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
 
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.
+
renewal_period_state reaches 0. The co-owners have the ability to refuse a proposed change as a setting change transaction 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.
 
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.
 
* 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.
 

Latest revision as of 08:47, 23 November 2020

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

spending variable types

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 spending

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.

setting modify transaction

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