Date: Fri, 20 Sep 2019 05:14:59 +0000
To: John Tromp <john.tromp@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <VuvyS-ZYh7UJON2y6iCp0KtCTKFqOxIqPzNETPForaK5QHBOoj4LxOVlsaDFb-c__t6GRYD8ZHWkQagDucyFD3kjElZhSuHvhen1RzqLxvQ=@protonmail.com>
In-Reply-To: <CAOU__fznZ4EznXPoiM5E2HaTzafZQ3dKQmXHOPaG8PzASiOFcg@mail.gmail.com>
References: <mailman.1791.1568888841.8631.bitcoin-dev@lists.linuxfoundation.org>
	<CAOU__fw11EmAJzay7-H7X3my5+xNGGo_BS6_1hphauPXTgbw8Q@mail.gmail.com>
	<IQ52_xPiESoJFzOk3QzRDJth00dtYquOnBkG3NXrORK0FrmIaCXf0Gxrnv-AYV94Q0sRLt03ejZyhOk3ZMhnPikoIkvG77ZRqhBbl86QucU=@protonmail.com>
	<CAOU__fznZ4EznXPoiM5E2HaTzafZQ3dKQmXHOPaG8PzASiOFcg@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble
Precedence: list

Good morning John,

> dear ZmnSCPxj,
>
> > Which I suppose is my point: you lose some of the "magic shrinking bloc=
kchain" property in implementing relative locktimes, as you now increase th=
e data you have to store forever (i.e. the kernels).
>
> The "magic shrinking" of MW never applied to kernels. To validate the
> current UTXO set, you need to validate all the kernels, each of
> which is a Pedersen commitment to zero together with a Schnorr
> signature using said commitment as public key.

However, my understanding is that, at least with the original mimblewimble.=
txt from Jedusor, the signatures and the Pedersen-commitment-to-0 could all=
 be aggregated into a single signature and Pedersen-commitment-to-0, if we =
were to use Schnorr-like signatures.
(it is possible I misunderstand this; I am not in fact a cryptographer.
Indeed, the original mimblewimble.txt mentions having to store every `k*G` =
and every signature attesting to it, although does not mention Schnorr and =
might not have considered the possibility of signature aggregation when usi=
ng Schnorr-like signatures.
There could be security issues I am unaware of, for example.)

In addition, the mimblewimble.pdf from andytoshi includes a "Sinking Signat=
ures" section, which to my understanding, combines absolute-locktime kernel=
s with partial O(log n) aggregation of the signatures that attest it.
Again, it is possible I misunderstand this.

It seems to me that neither technique is possible with relative locktime ke=
rnels.
Again, this may be merely my ignorance of such.

In any case, this is mostly moot and I ask only out of curiosity in order t=
o know more about kernels in non-relative-locktime MimbleWimble chains.


>Then you need to check
> that the sum of UTXO commitments (outputs) minus the summed block
> rewards times G (inputs) equals the sum of kernel commitments.
> Basically, the same check that is applied to individual transactions.
> > Decker-Russell-Osuntokun ("eltoo") is harder due to the `SIGHASH_NOINPU=
T` requirement.
> > I have tried to derive an equivalent to this `SIGHASH_NOINPUT` somehow =
by considering that the "reference to previous kernel" as being akin to the=
 Bitcoin transaction input referring to a previous output, however it seems=
 to be not easy to create a retargatable "reference to previous kernel" in =
this way.
>
> The Grin "Elder channel" design of [3] is similar in spirit to eltoo
> though, as the revocation transaction can be combined with the final
> close transaction to counter any closing attempt to an obsolete state.
> The design also offers some bandwidth savings compared to the
> Poon-Dryja design.

This seems interesting.
I shall look into this further.

Regards,
ZmnSCPxj