Date: Thu, 19 Sep 2019 15:15:00 +0000
To: John Tromp <john.tromp@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <IQ52_xPiESoJFzOk3QzRDJth00dtYquOnBkG3NXrORK0FrmIaCXf0Gxrnv-AYV94Q0sRLt03ejZyhOk3ZMhnPikoIkvG77ZRqhBbl86QucU=@protonmail.com>
In-Reply-To: <CAOU__fw11EmAJzay7-H7X3my5+xNGGo_BS6_1hphauPXTgbw8Q@mail.gmail.com>
References: <mailman.1791.1568888841.8631.bitcoin-dev@lists.linuxfoundation.org>
	<CAOU__fw11EmAJzay7-H7X3my5+xNGGo_BS6_1hphauPXTgbw8Q@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
Subject: Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble
Precedence: list

Good morning John,


> > However, I believe that Lightning and similar offchain protocols are no=
t possible on MimbleWimble, at least if we want to retain its "magical shri=
nking blockchain" property.
>
> MimbleWimble can easily incorporate relative lock heights, in addition
> to absolute lock heights. Grin and Beam have included the latter since
> launch.
>
> Grin's proposal for relative lock heights is at [1] with discussion at [2=
].
> Based on these, Grin also has a rough design for payment channels at [3].
>
> Beam included relative lock heights in its recent HardFork [4] and has
> a payment channel design at [5].
>

Thank you for this information.
I am aware that absolute locktimes were possible in MimbleWimble.

However, it does seem to imply that kernels are not compressible (unlike th=
e original MimbleWimble where the kernel is just an empty string and thus n=
ever stored).
So at least for kernels of relative locktimes, are not pruneable and will c=
ontribute to blockchain size.
(I believe I saw some proposal for absolute locktimes that allow some amoun=
t of aggregation/pruning of absolute-locktime kernels from the mimblewimble=
.pdf by andytoshi.)

Which I suppose is my point: you lose some of the "magic shrinking blockcha=
in" property in implementing relative locktimes, as you now increase the da=
ta you have to store forever (i.e. the kernels).
It is not a *total* loss of the "magic shrinking blockchain", I see now, ho=
wever.

Still, it does see worth the cost of accepting having to store kernels fore=
ver in exchange for being able to layer on top of a MimbleWimble blockchain=
.

It seems to me that Poon-Dryja and Decker-Wattenhofer can be "directly" por=
ted over to any MimbleWimble blockchain with relative locktimes.
Reference [5] seems to be Poon-Dryja ported over to using relative locktime=
s for MimbleWimble.


Decker-Russell-Osuntokun ("eltoo") is harder due to the `SIGHASH_NOINPUT` r=
equirement.
I have tried to derive an equivalent to this `SIGHASH_NOINPUT` somehow by c=
onsidering that the "reference to previous kernel" as being akin to the Bit=
coin 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.


In any case, it seems to me that the loss of SCRIPT does not prevent a Mimb=
leWimble blockchain from using an offchain updateable cryptocurrency system=
.

Regards,
ZmnSCPxj