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
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
|
Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C62AC68
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 20:49:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com
[209.85.217.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 225D212A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 20:49:03 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so47366904lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Aug 2015 13:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=L/Ak9H4W/cfXVUI6iIYrDMpmB7NF01bZKe85N4kjXJE=;
b=1GMTA0ctk9Rv7Dm9kPg2rf2v41iohUbW0weRiMnNkQFMgrpAz4X0pkYeigMPxibd1P
9rd3DzQmXn3zKjaxFCDZlRHMzneUR+LRPpxjo3TUyL+fHRoqcsqcYe1CA5Ac4oX+Wzte
gKYmDkSTmFg4OAE9t+CmzI0ldkXFfudPgMq52Yf62z43GmlU1pH+zi37u/Nspe+SVTRX
LWWzFMuAClPXP7196mB/YYAYmXmVNKAmTPopd6taC2sy1uA4rEtr6B/op/+4hjMx69FX
TSnR/tt0182NL89CzyQw3ZeC+iCdRB+Pe8R15K/SR+Zfjh/0QYZBRyjTL5VEvmSxsCXQ
Bokg==
X-Received: by 10.112.137.164 with SMTP id qj4mr17331847lbb.105.1439153341391;
Sun, 09 Aug 2015 13:49:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Sun, 9 Aug 2015 13:48:41 -0700 (PDT)
In-Reply-To: <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<55C79FF0.8040100@thinlink.com>
<CAOG=w-skYq84=PtN45FB-dGoY1783Jz7K1T16e2JVGjLazWuyA@mail.gmail.com>
<CAAO2FKHyNC6PT+i2pYo88eeb-wdkJdeVjmqzC=PetyF6yO=+Lw@mail.gmail.com>
<CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Sun, 9 Aug 2015 21:48:41 +0100
Message-ID: <CAAO2FKFvDfzgeWew8SNAQAa2avRSRWWaqp_WL9igFogJw0L9GQ@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=089e0115fd1cb0ebcc051ce6ff8f
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAD_CREDIT,BAYES_00,
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] What Lightning Is
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sun, 09 Aug 2015 20:49:04 -0000
--089e0115fd1cb0ebcc051ce6ff8f
Content-Type: text/plain; charset=UTF-8
Thanks Mark.
Ok next obvious question (apologies for all of these but it seems you are
the authority on Lightning here). Is the Lightning system limited in the
number of hops there can be in the payment channel? I am looking at the
initial Lightning slides presented in February and it looks like the
locktime decrements by 1-day along each hop. So the more hops there are the
longer my bitcoins are potentially locked up for?
On 9 August 2015 at 21:18, Mark Friedenbach <mark@friedenbach.org> wrote:
> Child pays for parent, and potentially future sighash modes implemented in
> the checksig2 operator lightning needs anyway which enable adding inputs to
> provide additional fee.
> On Aug 9, 2015 1:15 PM, "Hector Chu" <hectorchu@gmail.com> wrote:
>
>> In the Lightning network it is assumed that the balances can always be
>> settled on the blockchain if any of the parties along the channel has a
>> problem. What if the fee on the settlement transactions is not high enough
>> to enter the blockchain? You can't do replace-by-fee after the fact. Do the
>> fees always have to assume worst case scenarios on the Bitcoin fee market?
>>
>> On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Tom, you appear to be misunderstanding how lightning network and
>>> micropayment hub-and-spoke models in general work.
>>>
>>> > But neither can Bob receive money, unless payment hub has
>>> advanced it to the channel (or (2) below applies). Nothing requires the
>>> payment hub to do this.
>>>
>>> On the contrary the funds were advanced by the hub on the creation of
>>> the channel. There is no credit involved. if the funds aren't already
>>> available for Bob to immediately claim his balance, the payment doesn't go
>>> through in the first place.
>>>
>>> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>>>>
>>>> > Don't turn Bitcoin into something uninteresting, please.
>>>>
>>>> Consider how Bob will receive money using the Lightning Network.
>>>>
>>>> Bob receives a payment by applying a contract to his local payment
>>>> channel, increasing the amount payable to him when the channel is
>>>> closed.
>>>>
>>>> There are two possible sources of funding for Bob's increased claim.
>>>> They can appear alone, or in combination:
>>>>
>>>>
>>>> Funding Source (1)
>>>> A deposit from Bob's payment hub
>>>>
>>>> Bob can receive funds, if his payment hub has made a deposit to the
>>>> channel. Another name for this is "credit".
>>>>
>>>> This credit has no default risk: Bob cannot just take payment hub's
>>>> deposit. But neither can Bob receive money, unless payment hub has
>>>> advanced it to the channel (or (2) below applies). Nothing requires the
>>>> payment hub to do this.
>>>>
>>>> This is a 3rd-party dependency totally absent with plain old bitcoin.
>>>> It will come with a fee and, in an important way, it is worse than the
>>>> current banking system. If a bank will not even open an account for Bob
>>>> today, why would a payment hub lock up hard bitcoin to allow Bob to be
>>>> paid through a Poon-Dryja channel?
>>>>
>>>>
>>>> Funding Source (2)
>>>> Bob's previous spends
>>>>
>>>> If Bob has previously spent from the channel, decreasing his claim on
>>>> its funds (which he could have deposited himself), that claim can be
>>>> re-increased.
>>>>
>>>> To avoid needing credit (1), Bob has an incentive to consolidate
>>>> spending and income in the same payment channel, just as with today's
>>>> banks. This is at odds with the idea that Bob will have accounts with
>>>> many payment hubs. It is an incentive for centralization.
>>>>
>>>>
>>>> With Lightning Network, Bob will need a powerful middleman to send and
>>>> receive money effectively. *That* is uninteresting to me.
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
--089e0115fd1cb0ebcc051ce6ff8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks Mark.<div>Ok next obvious question (apologies for a=
ll of these but it seems you are the authority on Lightning here). Is the L=
ightning system limited in the number of hops there can be in the payment c=
hannel? I am looking at the initial Lightning slides presented in February =
and it looks like the locktime decrements by 1-day along each hop. So the m=
ore hops there are the longer my bitcoins are potentially locked up for?</d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 9 Aug=
ust 2015 at 21:18, Mark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto=
:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Child pays for pa=
rent, and potentially future sighash modes implemented in the checksig2 ope=
rator lightning needs anyway which enable adding inputs to provide addition=
al fee.</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On Aug 9, 2015 1:15 PM, "Hector Chu" &=
lt;<a href=3D"mailto:hectorchu@gmail.com" target=3D"_blank">hectorchu@gmail=
.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">In the Lightning network it is assumed that the balances c=
an always be settled on the blockchain if any of the parties along the chan=
nel has a problem. What if the fee on the settlement transactions is not hi=
gh enough to enter the blockchain? You can't do replace-by-fee after th=
e fact. Do the fees always have to assume worst case scenarios on the Bitco=
in fee market?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <span dir=3D=
"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Tom, you appear to be =
misunderstanding how lightning network and micropayment hub-and-spoke model=
s in general work.<span><br><br>> But neither can Bob receive money, unl=
ess payment hub has<br>
advanced it to the channel (or (2) below applies).=C2=A0 Nothing requires t=
he<br>
payment hub to do this.<br><br></span></div>On the contrary the funds were =
advanced by the hub on the creation of the channel. There is no credit invo=
lved. if the funds aren't already available for Bob to immediately clai=
m his balance, the payment doesn't go through in the first place.<br></=
div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <span dir=3D"ltr"=
><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev =
wrote:<br>
<br>
> Don't turn Bitcoin into something uninteresting, please.<br>
<br>
Consider how Bob will receive money using the Lightning Network.<br>
<br>
Bob receives a payment by applying a contract to his local payment<br>
channel, increasing the amount payable to him when the channel is closed.<b=
r>
<br>
There are two possible sources of funding for Bob's increased claim.<br=
>
They can appear alone, or in combination:<br>
<br>
<br>
Funding Source (1)<br>
A deposit from Bob's payment hub<br>
<br>
Bob can receive funds, if his payment hub has made a deposit to the<br>
channel.=C2=A0 Another name for this is "credit".<br>
<br>
This credit has no default risk: Bob cannot just take payment hub's<br>
deposit. But neither can Bob receive money, unless payment hub has<br>
advanced it to the channel (or (2) below applies).=C2=A0 Nothing requires t=
he<br>
payment hub to do this.<br>
<br>
This is a 3rd-party dependency totally absent with plain old bitcoin.<br>
It will come with a fee and, in an important way, it is worse than the<br>
current banking system.=C2=A0 If a bank will not even open an account for B=
ob<br>
today, why would a payment hub lock up hard bitcoin to allow Bob to be<br>
paid through a Poon-Dryja channel?<br>
<br>
<br>
Funding Source (2)<br>
Bob's previous spends<br>
<br>
If Bob has previously spent from the channel, decreasing his claim on<br>
its funds (which he could have deposited himself), that claim can be<br>
re-increased.<br>
<br>
To avoid needing credit (1), Bob has an incentive to consolidate<br>
spending and income in the same payment channel, just as with today's<b=
r>
banks.=C2=A0 This is at odds with the idea that Bob will have accounts with=
<br>
many payment hubs.=C2=A0 It is an incentive for centralization.<br>
<br>
<br>
With Lightning Network, Bob will need a powerful middleman to send and<br>
receive money effectively.=C2=A0 *That* is uninteresting to me.<br>
<br>
<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><br></div>
</div></div><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>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
--089e0115fd1cb0ebcc051ce6ff8f--
|
