Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4615DC004C for ; Tue, 4 Aug 2020 01:39:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 3CEFE878A8 for ; Tue, 4 Aug 2020 01:39:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZP45xaAdj4V for ; Tue, 4 Aug 2020 01:39:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by hemlock.osuosl.org (Postfix) with ESMTPS id 3CE6386FDE for ; Tue, 4 Aug 2020 01:39:04 +0000 (UTC) Date: Tue, 04 Aug 2020 01:38:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1596505140; bh=51/wKMSAzG+kFijmbTbLssUzfo42yGDtn/oF0w0JyTc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Y9FPDQGhHnKKpVI6aG772Uk86QALlEJPHguGMomZVtP26VW7PbQkLndrTEbrgzzl/ fC6xPUZCqjK0CV66tt9ZWmy3WEHRjOa48cq3XzUCguD+tQBslXkwGguCl4c/b5oW7N T9G4nXr0lcKfLuMfa3pVOa+UeyhsKGud+8OKzpGs= To: Richard Myers From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 01:39:06 -0000 Good morning Richard, > Thanks AJ for the updated BIP - very exciting! > > I'm also interested in this in the context of a Taproot version of Decker= -Russell-Osuntokun (eltoo).=C2=A0Thanks ZmnSCPxj for summarizing your thoug= hts on how this would work. I have had some difficulty understanding when s= omeone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this is a c= lever demonstration of how the=C2=A0differences can be exploited. > > I sketched out the protocol you described to help my understand it (below= ) and some questions came to mind: > > 1) If you do a collaborative close, would you need to use script-path spe= nding, or could you use key-path spending instead to improve privacy? It can (and should) use key-path, yes. > > 2) You mention 1.5 round trips for the (two party) MuSig signing session.= Must there be separate 1.5 round trips for each of the two signatures prod= uced (update, settlement) for each state update? I believe we can amortize this slightly by providing the `R` commitments fo= r the *next* signing session with the `s` for the *current* signing session= , reducing to 1.0 round trips. However, I believe a provably-safe 2-round MuSig (with composable MuSig eve= n!) is being worked on and should be released in a week or two, and if it i= s safe to provide the first round of the *next* session with the final roun= d of the *current* session then we could reduce it to just one (large) mess= age send per update. > > 3) A related question: can the 1.5 round trips for signing be combined wi= th the 1.5 round trips required to update the channel (ie. A signs settleme= nt tx, B signs settlement & update txs, A signs update tx)?=C2=A0 > > Perhaps something like this: > =C2=A0-> A provides partial signature for settlement tx > =C2=A0<- B provides complete signature for settlement tx and partial sign= ature for update tx > =C2=A0-> A provides complete signature for update tx My understanding (which might be incorrect!) is that it should be safe to p= erform the signing sessions for the settlement and update txes simultaneous= ly, i.e. * round 1: send `R` commitments for both update and settlement tx (can be s= ent with round 3 of previous signing session). * round 2: send `R` for both update and settlement tx. * round 3: send `s` for both update and settlement tx. Depending on how we do the HTLCs / PTLCs, we might also need to send signat= ures for all HTLCs, in parallel with the update+settlement tx signatures, a= s well. > 4) I'm not sure why AJ's formulation included an addition sig(X), but oth= erwise is it similar to what you're suggesting? > =C2=A0=C2=A0https://lists.linuxfoundation.org/pipermail/lightning-dev/201= 9-May/001996.html This might have been the "chaperone signatures" proposed for `SIGHASH_NOINP= UT` / `SIGHASH_ANYPREVOUT` back then. This was supposed to protect against replaying a `SIGHASH_ANYPREVOUT` signa= ture in case of address reuse. I pointed out that it would be much simpler for a Lightning spec to provide= a privkey for a common `X` used by all Lightning nodes, and thus would not= really provide much better security in practice. I believe what we intend now is a form of hidden output tagging to protect = against signature replay. An output has to have a special taproot version in order to be spent with `= SIGHASH_ANYPREVOUT` or `SIGHASH_ANYPREVOUTANYSCRIPT` in the script path, an= d `SIGHASH_ANYPREVOUT`/`SIGHASH_ANYPREVOUTANYSCRIPT` is not usable with key= path spends. Regards, ZmnSCPxj