mimblewimble team mailing list archive
Mailing list archive
features flags in Outputs
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
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
- then the coinbase flag isn't needed outside of that.
- 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
(*) Tracking coinbases separate from other Outputs means that, at first
the reward owner must supply some proof that safely links to the creating
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
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
output is spent. The most basic incentive could be, that coinbases older
X thousand blocks is lost forever. Assumptions here: miners have their
keys online at least once every few days or weeks.