Implement stake maturity

[scravy]

Bitcoin has coinbase maturity which does not allow newly minted coins to be spent for a 100 blocks. Particl has a stake maturity of 225 blocks (nStakeMinConfirmations = 225; // 225 * 2 minutes).

In unit-e we removed the notion of coinbase maturity for now as the notion of maturity is split into reward maturity and stake maturity. Only reward maturity was implemented for now: Check block reward maturity instead of block maturity (#714) mostly as a preparation for having proposer reward pools and validator reward pools.

Currently stake, once used for staking, can immediately be used to propose the next block. This can be used to degrade the system in a PoW setting and premine a long chain. It is clear we do need stake maturity.

There are three areas touched by stake maturity:

• We need stake maturity as a security measure to prevent the before mentioned premining/grinding attacks
• If stake is blocked from being re-used for staking right after it slightly lowers the chances to propose once you actually proposed and might make it more benefitial for a proposer to propose a slightly smaller coin. This relates to
  • User bigger coins first to stake is not rational for the proposer (#762)
  • Make sure that X% of stake lead to X% chances to propose (#291)
• If stake is blocked form being re-used for staking right after it might affect the liveness of the system. Imagine you have just 10 eligible coins (UTXOs) and no proposer is eligible to propose at a given point in time. Then no one can propose and has to wait for the next round 16 seconds after. At the same time we have a maximum future blocktime so the number of tickets is limited to number of utxo * number of eligible time slots, none of which might be eligible in the worst case. We had an ADR coming up about that:
  • ADR-22 Coinstake Maturity (https://github.com/dtr-org/unit-e-docs/pull/63)

[castarco]

If this is implemented, then there's an extra open (minor) question:

• How do we compute the maturity of combined stake (when different inputs have different ages)?
  • Do we simply set the new combined coin's age to 0? Doesn't this create an incentive to not combine coins?
  • Do we separate the used stake from the other coins that we want to combine?
  • Not saying that it's very important to incentive coins combination, I just see two weak points here: helping to decrease (or to keep under control) UTXOs set's size, and helping proposers to maximize their probability to propose once the coin is mature enough.

[thothd]

If this is implemented, then there's an extra open (minor) question:

• How do we compute the maturity of combined stake (when different inputs have different ages)?

  • Do we simply set the new combined coin's age to 0? Doesn't this create an incentive to not combine coins?
  • Do we separate the used stake from the other coins that we want to combine?
  • Not saying that it's very important to incentive coins combination, I just see two weak points here: helping to decrease (or to keep under control) UTXOs set's size, and helping proposers to maximize their probability to propose once the coin is mature enough.

maturity is a security measurement so I would split security and "usability" in terms of the discussion. nevertheless the points are points, though the drawbacks you mentioned are kinda driven from a motivation to combine, but can also be arguments against combining :) I think we should discuss them in the stake combination issue

[Nizametdinov]

Currently stake, once used for staking, can immediately be used to propose the next block. This can be used to degrade the system in a PoW setting and premine a long chain.

It's better to say:

Currently UTXO, once created, can be used immediately to propose the next block. This can be used to degrade the system in a PoW setting and premine a long chain.

Any UTXO, not only coinbase outputs, must be older than stake maturity in order to be used as a stake. BTW that's how it works in Particl.

[Nizametdinov]

If stake is blocked from being re-used for staking right after it might affect the liveness of the system.

Maybe, we can define maturity in terms of both depth and time, for example

the coin must have depth at least 100 OR it must be at least 1 hour old.

[thothd]

If stake is blocked from being re-used for staking right after it might affect the liveness of the system.

Maybe, we can define maturity in terms of both depth and time, for example

the coin must have depth at least 100 OR it must be at least 1 hour old.

you're welcome to read about it here, under "PoSv3's History" anyway I wouldn't go this way it's complicated and prone to time related attacks. depth is a good and simple mechanism especially that everything else depends on it (e.g finalization) and there's adjusted target time per block