From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: John Tromp <john.tromp@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble
Date: Thu, 19 Sep 2019 15:15:00 +0000 [thread overview]
Message-ID: <IQ52_xPiESoJFzOk3QzRDJth00dtYquOnBkG3NXrORK0FrmIaCXf0Gxrnv-AYV94Q0sRLt03ejZyhOk3ZMhnPikoIkvG77ZRqhBbl86QucU=@protonmail.com> (raw)
In-Reply-To: <CAOU__fw11EmAJzay7-H7X3my5+xNGGo_BS6_1hphauPXTgbw8Q@mail.gmail.com>
Good morning John,
> > However, I believe that Lightning and similar offchain protocols are not possible on MimbleWimble, at least if we want to retain its "magical shrinking 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 the original MimbleWimble where the kernel is just an empty string and thus never stored).
So at least for kernels of relative locktimes, are not pruneable and will contribute to blockchain size.
(I believe I saw some proposal for absolute locktimes that allow some amount 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 blockchain" property in implementing relative locktimes, as you now increase the data you have to store forever (i.e. the kernels).
It is not a *total* loss of the "magic shrinking blockchain", I see now, however.
Still, it does see worth the cost of accepting having to store kernels forever 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" ported over to any MimbleWimble blockchain with relative locktimes.
Reference [5] seems to be Poon-Dryja ported over to using relative locktimes for MimbleWimble.
Decker-Russell-Osuntokun ("eltoo") is harder due to the `SIGHASH_NOINPUT` 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.
In any case, it seems to me that the loss of SCRIPT does not prevent a MimbleWimble blockchain from using an offchain updateable cryptocurrency system.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-09-19 15:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1791.1568888841.8631.bitcoin-dev@lists.linuxfoundation.org>
2019-09-19 11:16 ` John Tromp
2019-09-19 15:15 ` ZmnSCPxj [this message]
2019-09-19 15:47 ` John Tromp
2019-09-20 5:14 ` ZmnSCPxj
2019-09-19 7:52 ZmnSCPxj
2019-09-19 8:39 ` Martin Schwarz
2019-09-19 18:54 ` Lloyd Fournier
2019-09-20 12:22 ` Andrew Poelstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='IQ52_xPiESoJFzOk3QzRDJth00dtYquOnBkG3NXrORK0FrmIaCXf0Gxrnv-AYV94Q0sRLt03ejZyhOk3ZMhnPikoIkvG77ZRqhBbl86QucU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=john.tromp@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox