From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: John Tromp <john.tromp@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble
Date: Fri, 20 Sep 2019 05:14:59 +0000 [thread overview]
Message-ID: <VuvyS-ZYh7UJON2y6iCp0KtCTKFqOxIqPzNETPForaK5QHBOoj4LxOVlsaDFb-c__t6GRYD8ZHWkQagDucyFD3kjElZhSuHvhen1RzqLxvQ=@protonmail.com> (raw)
In-Reply-To: <CAOU__fznZ4EznXPoiM5E2HaTzafZQ3dKQmXHOPaG8PzASiOFcg@mail.gmail.com>
Good morning John,
> dear ZmnSCPxj,
>
> > 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).
>
> 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 using Schnorr-like signatures.
There could be security issues I am unaware of, for example.)
In addition, the mimblewimble.pdf from andytoshi includes a "Sinking Signatures" section, which to my understanding, combines absolute-locktime kernels 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 kernels.
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 to 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_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.
>
> 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
next prev parent reply other threads:[~2019-09-20 5: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
2019-09-19 15:47 ` John Tromp
2019-09-20 5:14 ` ZmnSCPxj [this message]
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='VuvyS-ZYh7UJON2y6iCp0KtCTKFqOxIqPzNETPForaK5QHBOoj4LxOVlsaDFb-c__t6GRYD8ZHWkQagDucyFD3kjElZhSuHvhen1RzqLxvQ=@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