Definitely a fan of compact blocks to mitigate some impact of a faster block
time. A few random thoughts below:
On range proof validation: Doing all we can to reduce duplicate range proof
transmission seems like a big win. I prefer the amended version in the last
email to the original proposal. Using a partial output rather than an output
identifier introduces a fair bit of complexity.
As far as I can tell, the specific construction of the output hash's preimage
has not been determined. If we move forward with this mechanism, it becomes
critically important that the hash covers the range proof itself. A situation
where the hash resolves ambiguously should be avoided at all costs.
On inputs being part of the scheme: Since an input is by itself little more
than a hash, it seems like the gain there is likely fairly small. We have thus
far avoided the need to uniquely identify inputs by anything other than what
output it is spending. I think I'd prefer inputs to be in the block in their
entirety.
This is a cool design! I think nailing down some of the specific aspects of the
design will require a bit of protocol testing but this makes sense as a
foundation to start with.
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
