mimblewimble team mailing list archive

[John Tromp <john.tromp@xxxxxxxxx>]

dear Antioch,

> The problem with outputs though is nodes only maintain data relating to
> _unspent_ outputs (the UTXO set).
> Spent outputs are removed and effectively act as if they never existed. This
> is a core tenet of the scalability (and privacy) of MW.
> So if we refer to an output we appear to be limited to only referring to an
> _unspent_ output.
> Which is fine initially, you create two txs, one with a kernel referencing
> an output in the earlier tx. But then things get complicated if the
> referenced output gets spent during (or even before) the timelocked period.

I don't think that's the problem. An output can't be doublespent,
and the referenced output should be one of its inputs,
so if the 2nd tx is to be valid, then the referenced output is still unspent.
The real problem seems to be that anyone doing a sync from genesis afterwards,
lacks the data to verify the relative timelock, since the referenced
output is obviously
gone from all later utxo sets.

> Prior kernels:
> Kernels live forever (at least today in Grin).
> Referencing a kernel from another kernel is "cleaner" (same MMR) than having
> a kernel reference an output (across two MMRs).
> The problem though is that kernels live forever.
> If we need to enforce uniqueness we need to do it across the global set of
> all kernels.
> We would need to maintain an unpruneable index of all kernels on all nodes.
> And the kernel set is only going to grow ever larger.

It appears that full nodes will need to keep a complete kernel history
in any case,
to aid new peers syncing.
Doesn't that make the cost of maintaining an index relatively
manageable for full nodes?

> So we would like to be able to implement this without relying on an index of
> all kernels.

For clarity, is this about how light clients can verify relative
locktimes without
having the full kernel history?
For the initial sync, they could first record the (presumably) short
list of all referenced kernels,
then simultaneously verify and use this list while checking all
historic kernels.

For an extension sync, there is an issue for new kernels referring
back to old kernels from the initial (or earlier) sync. This is where
Merkle proofs seem to be required to verify the height of the
referenced kernel. Is this where your first vs last seen comes in?

regards,
-John