1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4615DC004C
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
