mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

I'm fine with 2 Merkle trees. Seems like there won't be much that's non-witness in the kernel though.

- Igno

P.S. Loving all the mailing list activity today :)




-------- Original Message --------
Subject: Re: [Mimblewimble] Compact blocks
Local Time: March 7, 2017 11:24 AM
UTC Time: March 7, 2017 7:24 PM
From: merope07@xxxxxxxxxxxxxx
To: mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>


From: MoaningMyrtle@xxxxxxxxxxxxxx

It should be sufficient for the output and its rangeproof to be separately committed to the chain to prevent ambiguity. Committing to rangeproofs, which are witness data and can be ignored (at a trust tradeoff), will reduce flexibility.

This is a good point. I'm not opposed to the rangeproof and output having separate identifiers. In the context of the compact block discussion I wanted to emphasize the ability to unambiguously commit to a specific (output, range proof) pair to avoid a search problem that quickly becomes untenable, but if this comes in the form of two separate identifiers resolved independently, that should be fine.

Right. It might be better to to have two Merkle structures. I know Igno wanted only one, for simplicity, but I think it's easiest and most efficient for witness data to be in a parallel tree. So you have a tree with kernels, inputs, outputs, and in parallel you have a tree with the respective signatures, "input witnesses", and rangeproofs.

This makes things unambiguous: to find a rangeproof for an output, you look in the witness tree at the same position that you found the output in the data tree.

Input witnesses could be nothing, or maybe it makes sense for them to be full Merkle proofs that the referenced inputs are currently in the UTXO tree.