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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Return-Path: <gsanders87@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C7883C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:17:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id B6B08892B0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:17:26 +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 Q+HtUVUHTVxW
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:17:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
[209.85.208.50])
by hemlock.osuosl.org (Postfix) with ESMTPS id D628C889AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 17:17:25 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id de14so7768817edb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 10:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=po7oIPiT+rdmlyxiAryTFCeIoofBUHv1fn+s2iu1kdg=;
b=GcQGGF7MrKTqQSokY4RoTF3zpq4c4Qq0GxRLKNcuZrDrNSx0LwZRLMF9vWOMtQZEv0
WSazlPb944dU8E2UbU3xOGI+9d7MfOLB3474XHfd1QkRXUJove5Ua7sDjb0sqVa3cPZO
r0TMlY8eNwaaqZfbL4Df1J6lpxX4jyZ3AU9Rs7kIvVilBIPnZCuEd9+X9Ote1M0wvRHb
2tS+K4WajddzDwlbrafk3O2OFnRZpw0+KfGrXXsvh7mVLk1ZwozN6N0udZ25P5P3q0K5
XFIgYPJcEkZTL6qRY2CecNPX4bar7kgPVmk7h0CcBsYVBsC65eIhYWSxaPbrgCMmfpQW
/J7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=po7oIPiT+rdmlyxiAryTFCeIoofBUHv1fn+s2iu1kdg=;
b=VAILb4FVRykSyhOpqVj8fMbaHFVB82Ka/OF0irxEjKhJS/2MbrUaPQhRpECRalUMJu
FhZ0c7WFdLfyEwDK8RYmDJjKBurPQLAmE3E65+r3OZYMQ7Z44HT5NiBTpIScAx3EPC7a
tWCadRePQGS0Ew0181nDFvnAsMKO+8F8Af1aA51QH9fSbrYqWM6LWGynBfsmA+s5nash
yu3pEhjtIdYmyC7rBWfXKHMMTAGWMByKuLvbvEuRoFttjj3PL6OAUZ5IRHB2AuEeSA6Q
S7Hh3YJ9tEmsAy+oiovh1ZhXR+cSXJGn0anTi2P/6Y2MFGUzRO+t8jyrBOXboH9WCcDG
eBdQ==
X-Gm-Message-State: ANhLgQ1MfnaNC6OYR/vNN7LbpgiPEkYvRTx1Nis8/gO9eTZoNRlpXSyz
T4ZeAcav38W4onCA0zEIhHebkdOgOCAa7OjZfWU=
X-Google-Smtp-Source: ADFU+vvq6ITnH3Lr0AOOihXvXZ9v4o4NOPevapBC++nqTzkT7yBDaF2kNqRP689P7U4KV479HKrmnooHu/u777xPYRM=
X-Received: by 2002:aa7:c80a:: with SMTP id a10mr9421612edt.101.1585243044377;
Thu, 26 Mar 2020 10:17:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
<79753214-9d5e-40c7-97ac-1d4e9ea3c64e@www.fastmail.com>
<CAPv7TjZ45VD_5sGSFiQxmt981uDodq28mHOW=2LYLofXams43w@mail.gmail.com>
<87369v6nw3.fsf@gmail.com>
In-Reply-To: <87369v6nw3.fsf@gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 26 Mar 2020 13:17:13 -0400
Message-ID: <CAB3F3Dt0z5bDMpzRGGJxJV8KpCk_4XGF23MGmYVkLppRbG7Wnw@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008af83505a1c52871"
Cc: tom@commerceblock.com
Subject: Re: [bitcoin-dev] Statechain implementations
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: Thu, 26 Mar 2020 17:17:26 -0000
--0000000000008af83505a1c52871
Content-Type: text/plain; charset="UTF-8"
> Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?
Suggestion was in line with original proposal where no keys are changing
ever, just not presupposing existence of MuSig.
On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Ruben Somsen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > Regarding modification 1, I agree with ZmnSCPxj that
> > Decker-Wattenhofer is your next best option, given that eltoo is not
> > yet available. But if you are going to use a kickoff transaction, keep
> > in mind that every previous owner will have a copy of it. Because of
> > this, you can't include a fee, and will instead need to have a second
> > output for CPFP. This way a previous owner will at least have to pay
> > the fee if they want to publish it. Note that it's still an
> > improvement, because even if the kickoff transaction gets posted, it
> > basically becomes no different than what it would have been, had you
> > not used a kickoff transaction at all.
>
> It might be worth adopting the late fee binding we have in eltoo by
> having the kickoff transaction input spending the funding tx signed with
> sighash_single. This works because we only have 1 input and 1 output
> that we really care about, and can allow others to attach fees at
> will. That'd at least remove the need to guess the feerate days or
> months in advance and thus having to overestimate.
>
> > Regarding modification 2, I like it a lot conceptually. It hadn't
> > occurred to me before, and it's a clear security improvement. The only
> > question is something Greg Sanders mentioned: whether it's enough to
> > justify the added complexity of using 2P ECDSA. The alternative would
> > be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
> > possibly).
>
> Wouldn't that result in a changing pubkey at each update, and thus
> require an onchain move to be committed?
>
> > I'm looking forward to seeing statechains become a reality.
>
> That'd indeed be great :-)
>
> Cheers,
> Christian
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000008af83505a1c52871
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> Wouldn't that result in a changing pubkey at each=
update, and thus<br>require an onchain move to be committed?<div><br></div=
><div>Suggestion was in line with original proposal where no keys are chang=
ing ever, just not presupposing existence of MuSig.</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 26, 20=
20 at 1:15 PM Christian Decker via bitcoin-dev <<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ruben=
Somsen via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>><b=
r>
writes:<br>
> Regarding modification 1, I agree with ZmnSCPxj that<br>
> Decker-Wattenhofer is your next best option, given that eltoo is not<b=
r>
> yet available. But if you are going to use a kickoff transaction, keep=
<br>
> in mind that every previous owner will have a copy of it. Because of<b=
r>
> this, you can't include a fee, and will instead need to have a sec=
ond<br>
> output for CPFP. This way a previous owner will at least have to pay<b=
r>
> the fee if they want to publish it. Note that it's still an<br>
> improvement, because even if the kickoff transaction gets posted, it<b=
r>
> basically becomes no different than what it would have been, had you<b=
r>
> not used a kickoff transaction at all.<br>
<br>
It might be worth adopting the late fee binding we have in eltoo by<br>
having the kickoff transaction input spending the funding tx signed with<br=
>
sighash_single. This works because we only have 1 input and 1 output<br>
that we really care about, and can allow others to attach fees at<br>
will. That'd at least remove the need to guess the feerate days or<br>
months in advance and thus having to overestimate.=C2=A0 <br>
<br>
> Regarding modification 2, I like it a lot conceptually. It hadn't<=
br>
> occurred to me before, and it's a clear security improvement. The =
only<br>
> question is something Greg Sanders mentioned: whether it's enough =
to<br>
> justify the added complexity of using 2P ECDSA. The alternative would<=
br>
> be to simply use a regular 2-of-2 multisig (until Schnorr arrives,<br>
> possibly).<br>
<br>
Wouldn't that result in a changing pubkey at each update, and thus<br>
require an onchain move to be committed?<br>
<br>
> I'm looking forward to seeing statechains become a reality.<br>
<br>
That'd indeed be great :-)<br>
<br>
Cheers,<br>
Christian<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000008af83505a1c52871--
|
