Add block rewards minting contract

[ethanfrey]

Simplest iteration is a contract that holds N tokens, has a master key K, and has a fixed destination address (contract) D When desired K can mint n tokens, that will be added to address D. This will decrement N -= n.

This fulfills MvP requirements, but gives quite a bit of leeway (too much) to governance. A future issue will use fixed curves for token release as an alternative. Using some examples like ethereum, with a fixed release schedule

Implementation will make use of the existing escrow functionality, as mentioned in a comment. We will assume #347 is completed first for nice genesis references and to obviate the need for more additions to the lsc tool.

Needed enhancements to escrow:

• Add Initialization functionality to create an escrow in genesis (minting needed tokens?)
• Clean up escrow to behave more like distribution, where it queries its balance upon sending, rather than assume some local tally is correct. This allows an escrow to receive more funds after creation and makes it more robust.
• Add an entry to a sample genesis file with such an escrow to use in acceptance test scenarios

Bonus tasks:

• Any code cleanup in the package that arises while doing the above (this is an old module, done quickly, and could use a refresher)
• Allow use of header time rather than header height as a trigger for timeout. Since tendermint 0.27 the timestamp in the header should be considered "BFT time" (cannot be faked without collusion of majority of the nodes), and is a reliable and more predictable indicator than block height (especially when no-empty-blocks is enabled)

It should look something like:

• Sender = 0000... (burn address)
• Dest = fee collection address (same as gconf, maybe the distribution module using cond reference)
• Arbiter = governance multisig address (using cond reference from More friendly references for genesis file #347)
• Amount = set to maximum to be release tokens, which should be added to a cash/wallet for this contract
• Timeout = eg. 2 years in the future (or high block time)

Note that once this is implemented, we can also use this to provide time-released tokens (eg. 6 months after genesis) with a different config:

• Sender = address to receive tokens after lock-up period
• Dest, Arbiter = 00000 (never going to be sent)
• Amount = tokens to be released
• Timeout = when lock-up period ends
  The escrow will never be executed, but after the timeout, the tokens can be "returned" to the sender.

[alpe]

I need to look a bit into other chains minting model but can you answer some questions already for me to understand this better?

• Is it correct that no new tokens were created during the process but all exist up front and are just distributed/ released? As minting I understand creation of new tokens that had not existed before
• What triggers K to add tokens to address D ?
• Is account D managed off chain? (governance?)
• Is it correct that the distribution/ release logic for K runs within the app and not off chain?

[ethanfrey]

K is the governance (multisig) contract.
They have some plan... Decided off chain

Many devs were distrustful they would release according to plan and that would make payout less predictable, and more risky for validators, thus the idea of a hard-coded payout.

Account D would be the distribution contract we merge any day now.

[ethanfrey]

Benjamin was worried about semantics from legal side. We have an initial token supply as defined in the whitepaper, so we cannot pre issue tokens here.

He wants to define maximum amount of tokens ever to be minted, in order to differentiate block rewards (good) from inflation (bad).

I dunna if this matters, but it seems to be important semantics from the legal / business side, so let's just implement it as issuing new tokens

[ethanfrey]

Hmmm... after reflecting some. If we just relax the requirement of minting new coins, but rather lock them up, we can implement this with the escrow model.

In genesis:

• Create an escrow with:
  • Sender = 0000... (burn address)
  • Dest = fee collection address (same as gconf)
  • Arbiter = governance multisig address
  • Amount = set to maximum to be release tokens.
  • Timeout = a few billion...
• Create a cash entry for this escrow address, with same tokens as in Amount

Functionality:

• Arbiter can partially release the money in escrow, with a ReleaseEscrowMsg specifying how much to release, but only to desired recipient
• Arbiter can burn any money to ensure it is never spent
• Timeout produces an optional deadline for all block rewards
• There is no other way to release the money

This is basically what we need for the MvP.

If we go this route all we need to do is:

• Add Initializier to the escrow package
• Produce a list of predictable ids, like multisig and distribution (and maybe think of a better way to encode references later, such as supporting the more readableConditions not only Addresses... but that is a different issue)
• Maybe improve escrow to query balance from it's account, like done in distribution, rather than rely on a stored amount field to represent reality (notice the fragility of needed to set the amount two places above).

I think this is good enough for now, and we can get some road-testing on this, while working out a more proper distribution design

[ethanfrey]

Note: should add Acceptance Test / Scenario Test that tries this on a real network.
If needed for internal testing, we can make a simple cli tool, but this is only designed for our use.

Wait for larger discussion on governance tooling (will we provide graphical UI) before spending much time on cli tooling?

[alpe]

👍 I was aiming for escrow, too as it perfectly matched the case except for the token creation. I am glad that this is not necessary anymore.

[alpe]

Extracted "header time" into issue #392