Difference between revisions of "MIP-0004"

From Mochimo Wiki
Jump to: navigation, search
Line 25: Line 25:
 
* 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>.
 
* 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>.
 
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.
 
* reserved_balance --> this type of variable sets a minimum amount of MCM, as satoshi, in the TAG to reserve for payments to the <i>affair</i>.
 
+
<br><br>
 
The variable I am referring to will be called <I>spending</I>. And as a transaction is made to an affair contained in a TAG setting, the spending_state variable will decrease by the amount spent.
 
The variable I am referring to will be called <I>spending</I>. 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.
 
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.
 
At every reference period renewal, the spending_state will be reset to the original spending state stated in the setting.
<br>
+
<br><br>
 
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.  
 
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
 
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 <I>spending</I> variable. As the setting is updated, the renewal_period_state should not be forced to change.
 
variable_type as the previously setting, but it can change the <I>spending</I> variable. As the setting is updated, the renewal_period_state should not be forced to change.
<br>
+
<br><br>
  
 
== Technical Details ==
 
== Technical Details ==

Revision as of 08:23, 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).

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.

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.