Date: Tue, 04 Aug 2020 01:38:55 +0000
To: Richard Myers <rich@gotenna.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <E0LvOEKdi7T-mG9yh9bnDXtsZGX1Ui269zQ5ydg4ws-HZtZ65stYLCc5G0tBjj3XnmCS0uEAxGcGweEoF5KllGClMpuKC8uQiIHfd6MYNQE=@protonmail.com>
In-Reply-To: <CACJVCgL+Ap9VBsDQp+KEuwhAkPZ1c0ACBRjHnB_qk-hi8_Uq7Q@mail.gmail.com>
References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au>
 <O_Zr7tM2TYwJdFS0o9RraXrtRPI4ZcVU65qcBpg-tvTPOqnGWkEUDQY5XqcihbUyAHF31L4isFWsD_u2SsSb8YzfjYDWiVXQsr6oAd9YXBY=@protonmail.com>
 <CACJVCgL+Ap9VBsDQp+KEuwhAkPZ1c0ACBRjHnB_qk-hi8_Uq7Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Precedence: list

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