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
|
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 C5AD68EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 11:15:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com
[209.85.208.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D213484F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 11:15:44 +0000 (UTC)
Received: by mail-ed1-f44.google.com with SMTP id y20so4349777edw.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 03:15:44 -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=wB4Ur8W3s+DSDy3eBvVhWgPGnSZZaze+n0zWMNO72ZE=;
b=KGKZddYh4tLOr31115Y4P4ry0goVy9UeIjeHuPZUF33Lm/qDV3OQLFUiM4xXSs1Adc
KxrKzZJSELk2ocyHz6IgdUzZre/bqrnkbBPsb9OMqfSzDEBJqBnjUrLPmfVmGsYQjo8E
/7W3GoT03qbeZJL1rsWbdt0VdRKl8huT6V0PaH2TsawoMB/09HIBORxytNMRr3MlkoFG
UTwFjKWZNxqkXyAr2Med7yfpN9OVtr6TxQmTPE4XRKtal+QxQN6LikEvsEzxMpdTK+Xg
e4+/SVsRbuEWyUuYQcNP7blfr9BmzAt5swPkvMbnBq+x+17NW05BuCJMCBrXih5XxrZl
n6fg==
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=wB4Ur8W3s+DSDy3eBvVhWgPGnSZZaze+n0zWMNO72ZE=;
b=VN7mGLxUOakdcCI03RReBVBqNDH2PHen2QWgGCGGqzegMIpWvSweGHgo6SJXp4vVvr
ycgeMo5e9MpEtGua+dXy3kk9Yhk39CoInSUNTvEG2WYw6W2xi3o/8L/GjW/29xTRLQh8
Oq+jELBHrH9OuwnQ7hYoxjf34ARtag0iOafgWEDujOJFjIQStgFVR7eTlzvfnINPN0jC
KGX3RaGyrKeDIhXolM7OpY9M7ROFHv7XIFAwRGGEq3OkpAARV0lA/A43IVYWLX++ppg1
iRtd+M1zXN4xm5WSFMrRjMZgx/MB+lEMiqoUyQCMtwqKTc/Nvf+JBNyEtX2aJU408UfE
+GfA==
X-Gm-Message-State: AA+aEWYWXj0NeyEdsTWrzkkInKv4dxBGjTl1/7mJvOStp6/tjAeszY/o
3ts9BPar1j1AzIpe/tvRFp8=
X-Google-Smtp-Source: AFSGD/WzPIPuk8CbRVBbXMGwwSYt2X/0lrqvwKcRIPO05AH97Qkvzwb5TvkXaDOz1ZcjzNFPAjkLMQ==
X-Received: by 2002:a17:906:590a:: with SMTP id
h10-v6mr1858111ejq.102.1545390943305;
Fri, 21 Dec 2018 03:15:43 -0800 (PST)
Received: from localhost ([2a02:aa16:1102:5480:b8c8:56f0:43e2:f1fe])
by smtp.gmail.com with ESMTPSA id z9sm6958835edr.61.2018.12.21.03.15.41
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Fri, 21 Dec 2018 03:15:42 -0800 (PST)
From: Christian Decker <decker.christian@gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <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>
<34A8F2C4-4732-4BE7-84F5-699B8D709D06@xbt.hk>
Date: Fri, 21 Dec 2018 12:15:37 +0100
Message-ID: <87woo3uo4m.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: Fri, 21 Dec 2018 23:29:30 +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: Fri, 21 Dec 2018 11:15:45 -0000
Johnson Lau <jl2012@xbt.hk> writes:
>> 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.
Correct, we're using the CLTV here as a weird "compare two numbers that
are committed to in the signatures" operation, by using locktimes in the
past as you correctly point out.
> 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
I keep forgetting about BIP68, but you're right, that should be
sufficient for our use-case and would safe us a few bytes.
>> 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.
I seem to keep mentally mixing different variants of the protocol in my
head. You are of course correct that the trigger and the update can be
considered the same, hence the 3 txs limit is right. Sorry for the
confusion :-(
|
