← Back to team overview

mimblewimble team mailing list archive

Re: Hash preimages, ZKCPs, atomic swaps and HTLC's

 

I understand Igno's concerns and think we are putting the wagon in front
of the horse a little bit here. Lightning Network related research is
great and any interoperability between Mimblewimble and Lightning Network
should be encouraged to be explored, but neither Lightning Network or
Mimblewimble are even remotely close to being functional and still very
much changing. Trying to make Mimblewimble compatible with Lightning
Network this early in development only adds complexity to the system. We
should get Mimblewimble functional first then hopefully by then Lightning
Network too is ready we can all figure out how to make Mimblewimble and
Lightning Network compatible with eachother. One step at a time everyone
:)

Cheers,
Gellert

> A tangential concern of mine is also the fact that those signatures need
> to be kept in the chain forever, in some form of another. While sinking
> signatures as formulated in your (Andrew Poelstra) paper can be
> problematic, I think the general concept is interesting. And the more
> information we add to the signed message, the more difficult aggregation
> will be.
>
> By only including fees in the message, I had some hopes that some summable
> signature scheme could still be formulated. A more complex composition is
> likely to make aggregation completely impossible.
>
> An alternative could be to add Schnorr partial signatures (or some
> equivalent) signing the empty string, paired with the soon-to-be-renamed
> excess value. The Schnorr signatures could be aggregated in each block or
> group thereof and the soon-to-be-renamed excess value could eventually be
> pruned. However there are a couple issues remaining with this approach
> (mainly detecting which excess value is safe to prune) so I'm not
> convinced it's viable either.
>
> I just want to make sure we're all aware of the trade-offs, especially
> when there's interference with our scalability, privacy or simplicity
> goals.
>
> - Igno
>




References