mimblewimble team mailing list archive

["Simon B." <simon.bohlin@xxxxxxxxx>]

Hi,

I'm trying to understand the "features flags" in Outputs and  looking for
pointers or discussion on the these flags.
Today they're used only to mark coinbase transactions.

1. What other things would we want to have in this features bit field?

2. Any future upgrades that depend on having features flags?

3. Is the coinbase flag really needed?

The information the coinbase flag carries is logically needed only twice;
(0) when a coinbase reward Output is created, and (1) when that Output is
spent. To validate the spending step I expect to also need to have the block
it came from to verify with, or keep the same information safely cached
and hashed.

In the code I've seen this "proof of concept" for lock height:

> // proof of concept - set lock_height on the tx
> let lock_height = chain_tip.height;

Will this feature be kept?

Either we have a lock height feature at least for already mined
transactions;
  - then the coinbase flag isn't needed outside of that.
Or not;
  - then reward outputs could be stored separately, so they don't really
appear in the UTXO set before they mature (>=1000 blocks). Possibly more
efficient to store. Simplifies Outputs but adds complexity elsewhere(*).

In both variants, the coinbase flag isn't needed on outputs.

Thoughts on this?

If we still need other features flags, then having coinbase as a flag is
probably the simplest way to do coinbases and minimise complexity.


All the best
Simon


PS.
(*) Tracking coinbases separate from other Outputs means that, at first
spend,
the reward owner must supply some proof that safely links to the creating
block.
It means trading the coinbase feature flag bit for some other data structure
to track which coinbases have been claimed to prevent double spends.

It could happen that miners want to keep rewards unspent, thinking they are
somehow nicer (more rare?) than other Outputs, and it'd benice to
incentivise
joining rewards to decrease the total size of UTXO set.
That requires special casing either where all transactions are validated,
or more preferably (=less work), only in the code that checks when a
coinbase
output is spent. The most basic incentive could be, that coinbases older
than
X thousand blocks is lost forever. Assumptions here: miners have their
private
keys online at least once every few days or weeks.