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: merop...@protonmail.com
To: mimblewimble@lists.launchpad.net <mimblewimble@lists.launchpad.net>
From: moaningmyr...@protonmail.com
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.
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
