From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A3541AD8 for ; Fri, 20 Sep 2019 05:15:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D823981A for ; Fri, 20 Sep 2019 05:15:09 +0000 (UTC) Date: Fri, 20 Sep 2019 05:14:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1568956506; bh=MZzc6SCRbXQJRynhNdSM/OOvqYQxbQWCuSRbbU2XtRY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=iXqmov+/t5lvTqNFpS5cmViaR97D+FIvJXHwA8cu9nAGa86HYo6eutExyU9YWz/aX Hd0MZBx1R0Spy/sHK5quaU73LH+95BSTStlLqo56lE0AAPRpNR7NcjNtFZfGMYn3wS VqtHOBLcs0Y6al0iuvbWTXcsJdr2OgWQp7Vynwmc= To: John Tromp From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 05:15:10 -0000 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