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
|
Return-Path: <benjamin.l.cordes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AA6F8273
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:18:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com
[209.85.218.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95A83D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 17:18:04 +0000 (UTC)
Received: by oigx81 with SMTP id x81so104335336oig.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 10:18:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=Ce3ElcZdHOU8HudricsBkqFXabCKxP9+7YnZZv7QqlE=;
b=G9nk1ejjyyybKtpM1fv9A2ocMgS3/mnAhIwBrfmCbgBdpNZ4mpPmYI9bk/8scKOUV6
AzDlrsYn+DmwPraQQmf4ibpD7dT50RikqOg9zR5qusuB91FE5YYsfowGdhb7cubuaX1Y
LUBqIsgKtW1ir3IFOZtwtWd2Pv2djGQmRUverBF8BRV+Bpj8/tIDZIoFGGDhEOQOvEcs
x87O6os6l/GfSfgY2BL+2gNwJHCSw2AbEY7AnJabLb0LqBAHKZWy2JVw5jL+299yo7Kf
d08PMk3OhysgbX3LVTd2p5OiNrT70iFqHJsji/FIkOp2Pb//SwG22RrWLstGLAVOaXv9
27MA==
MIME-Version: 1.0
X-Received: by 10.60.37.166 with SMTP id z6mr10240199oej.63.1435511884051;
Sun, 28 Jun 2015 10:18:04 -0700 (PDT)
Received: by 10.202.87.197 with HTTP; Sun, 28 Jun 2015 10:18:03 -0700 (PDT)
In-Reply-To: <CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com>
References: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl>
<CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com>
<CAOoPuRarNoPwLxVqjJ_g4b6HsWJecB-oCdfEjaknKbUnKdnmEg@mail.gmail.com>
<CALqxMTGXcbES5Pwz3cWO+PQK5kmf3rZ_i00=b=PBnO678XuF0A@mail.gmail.com>
<COL131-DS8E3DCDBD1A0F359206781CDAB0@phx.gbl>
<CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com>
Date: Sun, 28 Jun 2015 19:18:03 +0200
Message-ID: <CAOoPuRaR_A3ani3d_KVjc4oTfmLYbP52rLsqBEQMZ4gajqoV8A@mail.gmail.com>
From: Benjamin <benjamin.l.cordes@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=089e013c6856eb7b49051997276e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
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, 28 Jun 2015 17:18:05 -0000
--089e013c6856eb7b49051997276e
Content-Type: text/plain; charset=UTF-8
"You open a channel with a hub and through that channel send coins to
anyone accessible to the network."
Define hub *precisely* and you will find there are
some significant problems here.
a) does everyone know each other in the network? In Bitcoin transacting
parties exchange keys out of band. How do I know that Alice is owner of a
pubkey? I don't, and if don't know Alice I'm out of luck and can't transact
with here (or trust another PKI).
b) hubs need incentives. There are not going to put up collateral just for
nothing.
c) how is complexity reduced? I would speculate that most transactions are
one-time transactions in the time frame of days.
LT is a very interesting idea, but far from actual implementation.
On Sun, Jun 28, 2015 at 7:12 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> Think in terms of participants, not addresses. A participant in the
> lightning network has a couple of connections to various hubs, from which
> the participant is able to send or receive coin. The user is able to send
> coins to anyone connected to the lightning network by means of an atomic
> transaction through any path of the network. But the only payment from them
> that ever hits the chain is their settlement with the hub.
>
> Imagine there was a TCP/IP data chain and corresponding lightning network.
> Everyone connected to the network has an "IP" channel with their ISP.
> Through this channel they can send data to anywhere on the network, and a
> traceroute shows what hops the data would take. But when settlement
> actually occurs all the network sees is the net amount of data that has
> gone through each segment -- without any context. There's no record
> preserved on-chain of who sent data to whom, just that X bytes went through
> the pipe on the way to somewhere unspecified.
>
> So it is with lightning payment networks. You open a channel with a hub
> and through that channel send coins to anyone accessible to the network.
> Channels only close when a participant needs the funds for non-lightning
> reasons, or when hubs need to rebalance. And when they do, observers on the
> chain learn nothing more than how much net coin moved across that single
> link. They learn nothing about where that coin eventually ended up.
>
> So back to your original question, each channel can be considered to have
> a pseudonymous identity, and each new channel given a new identity. Channel
> closures can even be coinjoin'd when the other party is cooperating. But
> ultimately, lightning usefully solves a problem where participants have
> semi-long lived payment endpoints.
>
> On Sun, Jun 28, 2015 at 9:32 AM, Raystonn . <raystonn@hotmail.com> wrote:
>
>> Write coalescing works fine when you have multiple writes headed to the
>> same (contiguous) location. Will lightning be useful when we have more
>> unique transactions being sent to different addresses, and not just
>> multiple transactions between the same sender and address? I have doubts.
>>
>>
>> -----Original Message----- From: Adam Back
>> Sent: Sunday, June 28, 2015 5:37 AM
>> To: Benjamin
>> Cc: bitcoin-dev@lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
>>
>>
>> On 28 June 2015 at 12:29, Benjamin <benjamin.l.cordes@gmail.com> wrote:
>>
>>> I agree that naive scaling will likely lead to bad outcomes. They might
>>> have
>>> the advantage though, as this would mean not changing Bitcoin.
>>>
>>
>> Sure we can work incrementally and carefully, and this is exactly what
>> Bitcoin has been doing, and *must* do for safety and security for the
>> last 5 years!
>> That doesnt mean that useful serious improvements have not been made.
>>
>> Level2 and Lightning is not well defined. If you move money to a third
>>> party, even if it is within the constrained of a locked contract, then I
>>> don't think that will solve the issues.
>>>
>>
>> I think you misunderstand how lightning works. Every lightning
>> transaction *is* a valid bitcoin transaction that could be posted to
>> the Bitcoin network to reclaim funds if a hub went permanently
>> offline. It is just that while the hubs involved remain in service,
>> there is no need to do so. This is why it has been described as a
>> (write coalescing) write cache layer for Bitcoin.>
>>
>> I believe people expect lightning to be peer 2 peer like bitcoin.
>>
>> Adam
>> _______________________________________________
>> 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
>>
>
>
--089e013c6856eb7b49051997276e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">"<span style=3D"font-size:12.8000001907349px">You ope=
n a channel with a hub and through that channel send coins to anyone access=
ible to the network."</span><div><span style=3D"font-size:12.800000190=
7349px"><br></span></div><div><span style=3D"font-size:12.8000001907349px">=
Define hub <i>precisely</i> and you will find there are some=C2=A0significa=
nt=C2=A0problems here.=C2=A0</span></div><div><span style=3D"font-size:12.8=
000001907349px">a) does everyone know each other in the network? In Bitcoin=
transacting parties exchange keys out of band. How do I know that Alice is=
owner of a pubkey? I don't, and if don't know Alice I'm out of=
luck and can't transact with here (or trust another PKI).=C2=A0</span>=
</div><div><span style=3D"font-size:12.8000001907349px">b) hubs need incent=
ives. There are not going to put up collateral just for nothing.=C2=A0</spa=
n></div><div><span style=3D"font-size:12.8000001907349px">c) how is complex=
ity reduced? I would speculate that most transactions are one-time transact=
ions in the time frame of days.</span></div><div><span style=3D"font-size:1=
2.8000001907349px"><br></span></div><div><span style=3D"font-size:12.800000=
1907349px">LT is a very interesting idea, but far from actual implementatio=
n.</span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Jun 28, 2015 at 7:12 PM, 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"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><div><div>Think in terms of participants, not addresses. A particip=
ant in the lightning network has a couple of connections to various hubs, f=
rom which the participant is able to send or receive coin. The user is able=
to send coins to anyone connected to the lightning network by means of an =
atomic transaction through any path of the network. But the only payment fr=
om them that ever hits the chain is their settlement with the hub.<br><br><=
/div>Imagine there was a TCP/IP data chain and corresponding lightning netw=
ork. Everyone connected to the network has an "IP" channel with t=
heir ISP. Through this channel they can send data to anywhere on the networ=
k, and a traceroute shows what hops the data would take. But when settlemen=
t actually occurs all the network sees is the net amount of data that has g=
one through each segment -- without any context. There's no record pres=
erved on-chain of who sent data to whom, just that X bytes went through the=
pipe on the way to somewhere unspecified.<br><br></div>So it is with light=
ning payment networks. You open a channel with a hub and through that chann=
el send coins to anyone accessible to the network. Channels only close when=
a participant needs the funds for non-lightning reasons, or when hubs need=
to rebalance. And when they do, observers on the chain learn nothing more =
than how much net coin moved across that single link. They learn nothing ab=
out where that coin eventually ended up.<br><br></div>So back to your origi=
nal question, each channel can be considered to have a pseudonymous identit=
y, and each new channel given a new identity. Channel closures can even be =
coinjoin'd when the other party is cooperating. But ultimately, lightni=
ng usefully solves a problem where participants have semi-long lived paymen=
t endpoints.<br></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jun 28, 2015 at 9:32 A=
M, Raystonn . <span dir=3D"ltr"><<a href=3D"mailto:raystonn@hotmail.com"=
target=3D"_blank">raystonn@hotmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">Write coalescing works fine when you have multiple wri=
tes headed to the same (contiguous) location.=C2=A0 Will lightning be usefu=
l when we have more unique transactions being sent to different addresses, =
and not just multiple transactions between the same sender and address?=C2=
=A0 I have doubts.<br>
<br>
<br>
-----Original Message----- From: Adam Back<br>
Sent: Sunday, June 28, 2015 5:37 AM<br>
To: Benjamin<br>
Cc: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit<di=
v><div><br>
<br>
On 28 June 2015 at 12:29, Benjamin <<a href=3D"mailto:benjamin.l.cordes@=
gmail.com" target=3D"_blank">benjamin.l.cordes@gmail.com</a>> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I agree that naive scaling will likely lead to bad outcomes. They might hav=
e<br>
the advantage though, as this would mean not changing Bitcoin.<br>
</blockquote>
<br>
Sure we can work incrementally and carefully, and this is exactly what<br>
Bitcoin has been doing, and *must* do for safety and security for the<br>
last 5 years!<br>
That doesnt mean that useful serious improvements have not been made.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Level2 and Lightning is not well defined. If you move money to a third<br>
party, even if it is within the constrained of a locked contract, then I<br=
>
don't think that will solve the issues.<br>
</blockquote>
<br>
I think you misunderstand how lightning works.=C2=A0 Every lightning<br>
transaction *is* a valid bitcoin transaction that could be posted to<br>
the Bitcoin network to reclaim funds if a hub went permanently<br>
offline.=C2=A0 It is just that while the hubs involved remain in service,<b=
r>
there is no need to do so.=C2=A0 This is why it has been described as a<br>
(write coalescing) write cache layer for Bitcoin.><br>
<br>
I believe people expect lightning to be peer 2 peer like bitcoin.<br>
<br>
Adam<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>
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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--089e013c6856eb7b49051997276e--
|
