← Back to team overview

mimblewimble team mailing list archive

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

 

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



-------- Original Message --------
Subject: Re: [Mimblewimble] Hash preimages, ZKCPs, atomic swaps and HTLC's
Local Time: January 20, 2017 7:21 AM
UTC Time: January 20, 2017 3:21 PM
From: apoelstra@xxxxxxxxxxxxxx
To: Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>


Thanks Igno,


0. Ah, you're right. No big deal, though we do need to determine a clean and compact transaction format for all this.

0.33. Agreed. I have a paper submitted to a workshop which says more about how to do this.

As for Lightning, I hope to speak to Christian (Decker) and Rusty in the coming months. My understanding is that this signature trick should be sufficient as far as chain support goes, but on the LN side of things there are some potential complications creating channels in a CT environment.



Cheers

Andrew



On Fri, Jan 20, 2017 at 04:22:44AM -0500, Ignotus Peverell wrote:
> Apologies for the late reply, and thank you very much for sharing this.
>
> 0. This is nice. Recall that we need to sign the fee, so the message would be e || L || f but that shouldn't be an issue. We just need to think about it a little more to see how we can structure this nicely in a transaction.
>
> 0.33. We also need to think about practical support of Schnorr for multisig (i.e. sigtype). Not very difficult, just needs to be done.
>
> 0.67. Very neat indeed.
>
> Seems that as-is the construction is enough to support ZKCP and atomic swaps. Lightning is a little trickier but Thaddeus should know. Did you try to run this by Rusty as well?
>
> - Igno
>

--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom

Follow ups

References