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.

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.