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
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C34172A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Dec 2018 18:04:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CC747C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Dec 2018 18:04:48 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545329085; cv=none; d=zoho.com; s=zohoarc;
b=Crx8JqCcB9SD/AHdHv9UTUFQ8inCHqDFkVmlpyTMx2inVQVhR0T75ZN5FfCa0qkm0TDEYnUiIJ5to9C4Q70/LR+4X7jErVeX77cake8ICRsHQ01jztQQcjNcOHnfVDAz1gSKS4v/0dBmkxQvXbg7b0QbS0vc1+mQhAjh22w+Hgo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545329085;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=/kM76/T73x1okhC0Z2Dv9JfHfqWXlXwY+I8GDqW2arQ=;
b=JDNZ5f6CahuiACEpu4Zu96EkJlaFX0VGCf0y/WDPkfs2kLSBxyIhhN11GGzBiGL15M1RX+ef5PC1bqj8QH1uzpT6F7shtc/yNfBOo1pvQXgCSo15wucov8DNPdBgz/TkoUHOgajy8Uew84wkDBIjqdB5MpN+998o81DlpN3FLhI=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk;
spf=pass smtp.mailfrom=jl2012@xbt.hk;
dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
by mx.zohomail.com with SMTPS id 1545329083533232.61925281706613;
Thu, 20 Dec 2018 10:04:43 -0800 (PST)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <871s6cw1vt.fsf@gmail.com>
Date: Fri, 21 Dec 2018 02:04:37 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <34A8F2C4-4732-4BE7-84F5-699B8D709D06@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
<CAPv7TjYRVUGWCyFweootbMCJEkyFG4YOJ+M_N_N4j_t043bUfw@mail.gmail.com>
<87efadp3rl.fsf@gmail.com>
<195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk>
<871s6cw1vt.fsf@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 20 Dec 2018 21:58:07 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 20 Dec 2018 18:04:49 -0000
> On 21 Dec 2018, at 1:20 AM, Christian Decker =
<decker.christian@gmail.com> wrote:
>=20
> Johnson Lau <jl2012@xbt.hk> writes:
>> Correct me if I=E2=80=99m wrong.
>>=20
>> For the sake of simplicity, in the following I assume BIP118, 143, =
and
>> 141-P2WSH are used (i.e. no taproot). Also, I skipped all the =
possible
>> optimisations.
>>=20
>> 1. A and B are going to setup a channel.
>>=20
>> 2. They create one setup tx, with a setup output of the following
>> script: <s> CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign
>=20
> If we are using a trigger transaction the output of the setup
> transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a =
CLTV
> in there we would not have an option to later attach a collaborative
> close transaction that is valid immediately. Furthermore the timeout =
of
> the CLTV would start ticking down the exact moment the setup =
transaction
> is confirmed, hence whatever effect we are trying to achieve with that
> timelock is limited, and we have a limit to the total lifetime of the
> channel.
CLTV is absolute locktime. Only CSV will have the =E2=80=9Ctime =
ticking=E2=80=9D issue, but that=E2=80=99s not used here. The required =
locktime <s> is many years in the past. To collaboratively close, you =
just need to sign with SIGHASH_ALL, with a locktime s+1.
>=20
>> 3. They create the update tx 0, spending the setup output with =
NOINPUT
>> and locktime =3D s+1, to the update-0 output with the script: IF 2 =
As0
>> Bs0 2 CHECKMULTISIG ELSE <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG =
ENDIF
>=20
> Update 0 is usually what I call the trigger transaction. It takes the
> 2-of-2 multisig from the setup transaction and translates it into the
> two-branch output that further updates or settlements can be attached
> to. The settlement transaction attached to the trigger / update 0
> reflects the initial state of the channel, i.e., if A added 2 BTC and =
B
> added 1 BTC then settlement 0 will have 2 outputs with value 2 and 1
> respectively, with the user's keys (this can also be considered the
> refund in case of one party disappearing right away).
>=20
> The second branch in the script you posted is the update branch, which =
is
> not encumbered by a CSV, while the first branch is the one encumbered
> with the CSV and is called the settlement branch since we'll be
> attaching settlement txs to it.
>=20
> The CLTV looks correct to me and ensures that we can only attach any
> state >=3D s+1.
>=20
> So just to show the output script for state `i` how I think they are
> correct:
>=20
> ```
> OP_IF
> <timeout> OP_CSV 2 <As_i> <Bs_i> 2 OP_CHECKMULTISIG
> OP_ELSE
> <s+1> OP_CLTV OP_DROP 2 <Au> <Bu> 2 OP_CHECKMULTISIG=20
> ```
>=20
> And the input scripts for the update tx and the settlement tx
> respectively would be:
>=20
> ```
> OP_FALSE <Sig_Bu> <Sig_Au>
> ```
>=20
> and
>=20
> ```
> OP_TRUE <Sig_Bs_i> <Sig_As_i>
> ```
I think the use of OP_CSV (BIP112) is not needed here (although it =
doesn=E2=80=99t really harm except taking a few more bytes). All you =
need is to sign the settlement tx with a BIP68 relative locktime. Since =
this is a 2-of-2 branch, both parties need to agree with the relative =
locktime, so it is not necessary to restrict it through OP_CSV
>=20
>> 4. They create the settlement tx 0, spending the update-0 output with
>> As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs
>=20
> If I'm not mistaken the CSV needs to be in the scriptPubkey (or P2WSH
> equivalent) since segwit witnesses only allow pushes. Hence the script
> in point 3 needs to add that :-)
I believe you confused OP_CSV (BIP112) with BIP68. Relative locktime is =
enforced by BIP68 (i.e. setting the nSequence). OP_CSV indirectly =
enforces relative-locktime by checking the value of nSequence. BIP68 =
could work standalone without OP_CSV, while OP_CSV is dependant on =
BIP68. In the case of n-of-n eltoo state update, OP_CSV is not needed =
because all n parties need to agree with the same nSequence value of the =
settlement tx. This is enough to make sure the settlement tx has delayed =
settlement.
>=20
>> 5. They sign the setup tx and let it confirm
>=20
> They also need to sign (but not broadcast) update_0, in order to allow
> either party to initiate the closure if the counterparty become
> unresponsive. The order in which settlement_0 and update_0 are signed =
is
> not important by the way, so we can just batch these. The important =
part
> is that signing the setup acts as a commitment.
Sure. This is obvious.
>=20
>> 6. To update, they create the update tx 1, spending the setup output
>> with NOINPUT and locktime =3D s+2, to the update-1 output with the
>> script: IF 2 As1 Bs1 2 CHECKMULTISIG ELSE <s+2> CLTV DROP 2 Au Bu 2
>> CHECKMULTISIG ENDIF and create the settlement tx 1, spending the
>> update-1 output with As1 and Bs1 using relative-locktime, with 2
>> settlement outputs
>=20
> The output script of the updates are identical to the ones in the
> trigger or update_0 transaction, so they'd also need a CSV (this is =
why
> committing to the script structure with masking still works).
>=20
>> 7. To close the channel, broadcast update tx 1. Wait for several
>> confirmations. And broadcast settlement-tx-1
>=20
> We have to differentiate 2 cases: collaborative close and unilateral
> close. In the collaborative close we come to a mutual agreement that
> we'd like to take this latest state and settle. So we create a new
> transaction that spends the setup output, and add outputs according to
> the state we agreed upon, and we sign it. This transaction is
> immediately valid, and does not need to be signed with NOINPUT. So all
> the chain sees is a setup transaction with some inputs and one =
multisig
> output (singlesig with Schnorr) and a collaborative close transaction
> that spends the setup (also not signed with NOINPUT). About as normal =
as
> transactions in Bitcoin can get.
Collaborative close is always simple as I explained in the beginning
>=20
> In the unilateral case, one party isn't there anymore, or refuses to
> sign. So we take the trigger transaction (not signed with NOINPUT) and
> the latest update_n transaction (signed with NOINPUT) and broadcast
> them. Then we wait for the CSV timeout to expire, and then send the
> settlement transaction, which gives us the enforcement of the latest
> state that we agreed on. The chain sees a setup transaction and a
> trigger transaction (normal transactions for all intents and purposes,
> except for the output script of the trigger, but we can hide that with
> taproot), followed by two more transactions which are signed with
> NOINPUT. So 4 transactions in the worst case, of which 2 are special,
> and 2 transactions in the good case.
>=20
>=20
> So all in all I think it's a tradeoff between having a larger on-chain
> footprint (4 txs vs 3 txs in the worst case) and putting a fixed
> lifetime on the channel for the refund case if one party disappears
> right away. We'll probably find out what acceptable parameters are for
> these and where the cutoff points are :-)
If no one is cheating (i.e. only the last update is broadcast), you =
always need only 3 txs. Think about this: every update tx could be a =
trigger tx, and you can settle directly on a trigger tx, so effectively =
you eliminate trigger tx.
|
