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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CB63ED1D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Dec 2018 17:21:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com
[209.85.208.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6F30889
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Dec 2018 17:21:04 +0000 (UTC)
Received: by mail-ed1-f52.google.com with SMTP id h15so2412350edb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Dec 2018 09:21:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:date:message-id
:mime-version:content-transfer-encoding;
bh=YrbuWJH3lDqy9BXSQLEMVk8nXk+76qHo5fIPRrr5lEU=;
b=oWsfQhjuUNbbuuBRQqL5ap7iJIKTL9IVxF9qCaQKSJnOjycXD8Mye+IV6lmCP+0yYd
apU1/NB5DodxiAadk8mDkDwhtAsp+yznGLmBH0g/6Hy9iDCLIdnQ0GoWMx3qPc0bTfsG
8wfKpWDRf9HNzVWa8qqed6bZCYl0sWqcoNxK417idWQjAeN/5x9PDw2Y6HrznopTrgGA
pHq0N6sLsbtrVrrostze4pepe3IkBUhGOKB4xgXmkzvpCeWi/4AP4I1b9MS8CtgYi1Yc
y33HdsJO1fO6pWgfV1te7oC3e40OaLCnJ0QKvPY61rQb03orpoYPppX8rIa94JFmGyNY
CK2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
:message-id:mime-version:content-transfer-encoding;
bh=YrbuWJH3lDqy9BXSQLEMVk8nXk+76qHo5fIPRrr5lEU=;
b=OfMUVuxDpaHPuqBjBFTAgjH3TMGEyUUFjTMBJg/qw/BLEEFa8M6iNThrh18xx00Jpy
sv94kni0DSKZxd4nY8xlHI9NDJUXTlKw+QVajiS5KWrG+7jwFLxiWUGJXwie9ifMVnLs
lRQPd70HvsNXtVnysSyMIQT2waFNpkSm19yINQCM4yDVnUxKITdAmNT6ZPJz0ASJsUGn
j7J60Ito8xQgAVw/e7S/PzJ8GgBUv9SRyBG412OPcRmJmMh3ngZ597by65bLgSVoFv2t
hZdHxGUCJLUWLySuJL1gqPlXxQ26Yt1GqZVvJcT0PYy9p31trj3SqiECATnZotIu+xKP
HsQg==
X-Gm-Message-State: AA+aEWZawLN/l1TbC6211BRbXzylS8Kl6l77VHupHz8fN/0qqA+512r6
l9JGOg50tk7c0siOWZTxo+I=
X-Google-Smtp-Source: AFSGD/W6sh0l/Z+j6rb6jEnL/W+ca+gLgWWbOEDxUnQkJ8Jh3DXsczMcMaq5wyupQh65QnnICpyoPw==
X-Received: by 2002:a50:a086:: with SMTP id 6mr11925631edo.88.1545326463308;
Thu, 20 Dec 2018 09:21:03 -0800 (PST)
Received: from localhost ([2a02:aa16:1102:5480:b8c8:56f0:43e2:f1fe])
by smtp.gmail.com with ESMTPSA id
v43sm6456574edc.18.2018.12.20.09.21.00
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 20 Dec 2018 09:21:01 -0800 (PST)
From: Christian Decker <decker.christian@gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <195B4583-CE97-4C3A-9582-3C0C013CC1E9@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>
Date: Thu, 20 Dec 2018 18:20:54 +0100
Message-ID: <871s6cw1vt.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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 17:21:05 -0000
Johnson Lau <jl2012@xbt.hk> writes:
> Correct me if I=E2=80=99m wrong.
>
> 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.
>
> 1. A and B are going to setup a channel.
>
> 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
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.
> 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
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).
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.
The CLTV looks correct to me and ensures that we can only attach any
state >=3D s+1.
So just to show the output script for state `i` how I think they are
correct:
```
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
```
And the input scripts for the update tx and the settlement tx
respectively would be:
```
OP_FALSE <Sig_Bu> <Sig_Au>
```
and
```
OP_TRUE <Sig_Bs_i> <Sig_As_i>
```
> 4. They create the settlement tx 0, spending the update-0 output with
> As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs
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 :-)
> 5. They sign the setup tx and let it confirm
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.
> 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
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).
> 7. To close the channel, broadcast update tx 1. Wait for several
> confirmations. And broadcast settlement-tx-1
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.
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.
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 :-)
|
