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: <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 0447D13EB;
Thu, 3 Oct 2019 10:33:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com
[209.85.208.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12EBB189;
Thu, 3 Oct 2019 10:33:49 +0000 (UTC)
Received: by mail-ed1-f45.google.com with SMTP id h2so1989536edn.3;
Thu, 03 Oct 2019 03:33:49 -0700 (PDT)
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; bh=c1AP+RJ0NeQxMuarET0pMrAggF1fH4YB7aNat8+M8GI=;
b=DJxt1++NNqvRQkF4Go2JZRXdiUFwsa/JZAG+VqCvwjR3EtIott7rcsu4Vlpm0V+ZPk
71i3Kam8vvKQhTPr0x73XQg3JZlHdOUP62qMrWe0hityaE6NRw04rpNdLbx37a3VqVfh
dDkCzyRT47d8W0lidw52K04aueZWfBk5pRWCpFW/iVTwOR39Zac/MDBTjy5dAr2dxxFy
6GLbekyiZTrK16bQcMoen1Wu1CGXKorziBbDEZWrihM7/Xq7qaWXc6wbVqGwWqGJ6nfJ
Q2VQS6aYiCQ//fboR1j4TE+lH9Z/yt+tWsWtV+f4j2QcwVuhDhvTiJv2vOvgFPRnmDka
6Fyw==
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;
bh=c1AP+RJ0NeQxMuarET0pMrAggF1fH4YB7aNat8+M8GI=;
b=j/GtsfztgNGr89eYbuP/pJlEFYcOeGPmMcOXVQDRyznZl8FI/pxMq0BFpJVj9l9vA7
sV0Bju7IpYka2Fazsboh1+FWFr2zl6+TgU5FetiNyZqKll6kUGDFiDfNC9YxvnwbmBUa
MLv9QWrMNAL7nqhyO23kshmxtd3TJDqn7PDAj2cFOxOtiRCjAOYc4a5mb1ZcKLNG2WZk
DjKqA0p1JXbRVXBahFbikUabyrxI2y6S17B2qVEV2Xd+k7IWCERmK34q2LYdQtl9RMSb
wl6uCG8pGr/yfRNYNQzzr1s4sW+bwxHMoW8+lexJOEvqdK7rbzsVhvrxWxNSKE46GtDD
9dRg==
X-Gm-Message-State: APjAAAWUC3TPAydIDsWMpTc1V4wI3IVWG5sjGrYaMiD3hSFCnhOnUb/r
IfHDoWZ42d13U8tJIHwJqjygtxnaKVI=
X-Google-Smtp-Source: APXvYqzG1purW0v3aRN1OeK6AGNeXuXShZF/RiPgppRfNGtMF8m2hIWpLsH4KCnXLoEe/1Kuaepj3Q==
X-Received: by 2002:a17:906:20c7:: with SMTP id
c7mr6894135ejc.248.1570098828463;
Thu, 03 Oct 2019 03:33:48 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:437:6ae2:fddc:d532])
by smtp.gmail.com with ESMTPSA id l7sm394192edv.84.2019.10.03.03.33.47
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 03 Oct 2019 03:33:47 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <4zx7e_vHQr58myY5w_-bAjTk04LTGNknZudZs4wbUiOIoVKhL69M7k1eELCSuoBND2CtVXXzDFBHW4351cttIh80eP8jiaoO8cmbSefZmj4=@protonmail.com>
References: <87wodp7w9f.fsf@gmail.com>
<-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
<87tv8s7djq.fsf@gmail.com>
<4zx7e_vHQr58myY5w_-bAjTk04LTGNknZudZs4wbUiOIoVKhL69M7k1eELCSuoBND2CtVXXzDFBHW4351cttIh80eP8jiaoO8cmbSefZmj4=@protonmail.com>
Date: Thu, 03 Oct 2019 11:42:00 +0200
Message-ID: <87o8yy6u8n.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput /
anyprevout
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, 03 Oct 2019 10:33:51 -0000
ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
>> That is very much how I was planning to implement it anyway, using a
>> trigger transaction to separate timeout start and the actual
>> update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo
>> there shouldn't be an issue here :-)
>
> My understanding is that a trigger transaction is not in fact
> necessary for Decker-Russell-Osuntokun: any update transaction could
> spend the funding transaction output directly, and thereby start the
> relative timelock. At least, if we could arrange the funding
> transaction output to be spendable directly using `SIGHASH_NOINPUT` or
> variants thereof.
This is the case in which we don't have a pre-signed settlement
transaction (or in this case refund transaction) that uses a relative
timelock. In order to have a refund transaction we would need to have
the first update and settlement pair be signed before funding (otherwise
the funder isn't sure she is getting her funds back). Since that first
update and settlement pair do not need to be rebound (they can only ever
be bound to the funding transaction) they can be signed without
noinput/anyprevoutanyscript. If we use output tagging we would mandate
that this first update must be published, so that the funding output is
indistinguishable from a normal output, and the first update switches
from non-noinput/anyprevoutanyscript to enabling it. Collaborative
closes are still indistinguishable, unilateral closes require the
switch, but then would be identifiable anyway.
The one downside I can see is that we now mandate that unilateral closes
also publish the first update, which is a bit annoying.
>> While I do agree that we should keep outputs as unidentifiable as
>> possible, I am starting to question whether that is possible for
>> off-chain payment networks since we are gossiping about the existence of
>> channels and binding them to outpoints to prove their existence anyway.
>
> * Lightning supports unpublished channels, so we do not gossip some outpoints even though they are in fact channels underneath.
> * I confess the existence of unpublished channels in the spec fails to summon any reaction other than incredulity from me, but they exist nonetheless, my incredulity notwithstanding.
That is true, we do however selectively tell others about the channel's
existence (in invoices, our peers, ...) so I wouldn't consider that to
be the most secret information :-)
As for why they exist: nodes need to have the option of not announcing
their channels to reduce the noise in the network with channels that are
unlikely to be useable in order to forward payments. If every node were
to announce their channels we'd have a much larger routing table, mostly
consisting of unusable channels going to leafs in the
network. Furthermore, the sheer threat that there might be unannounced
channels adds uncertainty for attackers trying to profile nodes: "I see
only my channel with my peer, but he might have unannounced channels, so
I can't really tell whether the payment I forwarded to it is destined
for it or one of its unannounced peers".
> * Historical channels that have been cooperatively closed are no longer normally gossiped, so the fact that they used to be channels is no longer widely broadcast, and may eventually be forgotten by most or all of the network.
> * This means anyone who wants to record the historical use of Lightning will have to retain the information themselves, rather than delegating it to fullnodes everywhere.
Good point, it requires storing the ephemeral data from gossip, that's
not all that hard, but I agree that it puts up a small barrier for
newcomers.
|
