summaryrefslogtreecommitdiff
path: root/c5/2d22bf8f64d6fdf8d0b2973314a6eaef129096
blob: 6edd7807b3ee4c9ef0293fae922ecb313e2b85d7 (plain)
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
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9BB177AD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Aug 2015 18:54:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
	[209.85.223.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B92B41BC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  9 Aug 2015 18:54:25 +0000 (UTC)
Received: by iodb91 with SMTP id b91so91891156iod.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 09 Aug 2015 11:54:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=4QbNX4xas7zIoZyUuUKlTdzqYTWMfEavn+Gm9Y8r3Vo=;
	b=dCfNDliygEC8nDpEm6tHCqcdCg5Y7zIgBo2/nT9fK8JfvQ8b/YPqKB3kumqMM4towF
	2PVMovUrOrHBFouz6ydnN2aXU5W5iXcBnHsWeBDpqnGhIgHUrl2kNhJxoYkHwKlXtr2M
	FVNYbsNC+00iEFRV0KGwyrGVDUCqzaRvwDVDrH3eC1Njhzcyc/xhQhc+oJKHdO2NSdyX
	hBLuQ849ClGhZj3rjJwK1snAQ5YakKqPf8MJlMF8MAjeCLo6bkod9fFn6nm2Lxfjdzgj
	kULwNMmTzuhJD45FHYhWvzZVBM6OtUGPIua5xg3DijH5aq6tbX718t36YDIe0OAtwHpG
	Ecbg==
X-Gm-Message-State: ALoCoQkY7UCxDo0K4Msy8I+GbGkFxQsLWuXvnZwTrLnwTsgy/nnS+iL6LA9Db9gBW7do0cjeqISl
X-Received: by 10.107.35.138 with SMTP id j132mr20110291ioj.159.1439146465130; 
	Sun, 09 Aug 2015 11:54:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.158.140 with HTTP; Sun, 9 Aug 2015 11:54:05 -0700 (PDT)
X-Originating-IP: [50.0.37.37]
In-Reply-To: <55C79FF0.8040100@thinlink.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>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sun, 9 Aug 2015 11:54:05 -0700
Message-ID: <CAOG=w-skYq84=PtN45FB-dGoY1783Jz7K1T16e2JVGjLazWuyA@mail.gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=001a1140f4e6d59528051ce565bb
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAD_CREDIT,BAYES_00,
	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 18:54:27 -0000

--001a1140f4e6d59528051ce565bb
Content-Type: text/plain; charset=UTF-8

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
>

--001a1140f4e6d59528051ce565bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Tom, you appear to be misunderstanding how lightning =
network and micropayment hub-and-spoke models in general work.<br><br>&gt; =
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></div>On the contrary the funds were advance=
d by the hub on the creation of the channel. There is no credit involved. i=
f the funds aren&#39;t already available for Bob to immediately claim his b=
alance, the payment doesn&#39;t go through in the first place.<br></div><di=
v 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">&lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:<br>
<br>
&gt; Don&#39;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&#39;s increased claim.<br=
>
They can appear alone, or in combination:<br>
<br>
<br>
Funding Source (1)<br>
A deposit from Bob&#39;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 &quot;credit&quot;.<br>
<br>
This credit has no default risk: Bob cannot just take payment hub&#39;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&#39;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&#39;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">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>

--001a1140f4e6d59528051ce565bb--