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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EB71CAC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jun 2015 01:13:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com
[209.85.192.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B341176
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jun 2015 01:13:33 +0000 (UTC)
Received: by pdbci14 with SMTP id ci14so106581110pdb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jun 2015 18:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=subject:mime-version:content-type:from:in-reply-to:date:cc
:message-id:references:to;
bh=DC/qoKSR+28Sy8t60IbdoNlosafGPSLK68lwDBD+68E=;
b=fp7NkuoyDiJtJYlcvM9OAjH9rgw/mQtZkaRtAsS8yBAMHlPcKM5Jt7K32Bh+zEQxTg
FuMvucRxRtqnjbUFrj+r+DD99TuOTZlaqUhIelhk13ZoKHsbVmIQk36xDoCSVJaFlY1F
vKd5laBl7ktpI9pzLOeSlSayRvZHzcW2akctkSnoPsbWXPO45hKMfPgbMa5D00O+ej2b
WlgmUzS93n1yyZ53/BviumgPy2mIjOd6qrgm+MdwIWuD6WGYfWvH3n/rj5k0J1Xb9hfW
PyRuU9oneY0NVtRXcRof3Ca3JRsGyvKx8CGC9M2AIBE258qHR3RWm4mxR/vJlVR77JDw
WLVg==
X-Received: by 10.68.133.131 with SMTP id pc3mr26284629pbb.107.1435540412830;
Sun, 28 Jun 2015 18:13:32 -0700 (PDT)
Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by mx.google.com with ESMTPSA id
mt1sm40154524pbb.70.2015.06.28.18.13.30
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 28 Jun 2015 18:13:31 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_55A297D8-AD1A-4E32-ADB9-47086480D5A0";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CALqxMTGd1mB4Sra=ORV=d0y1v8KzUQnK8=MX2_MFP1NuMnPm+Q@mail.gmail.com>
Date: Sun, 28 Jun 2015 18:13:29 -0700
Message-Id: <E691526C-F6CD-40F4-9439-9B91A6444E2F@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>
<CABsx9T3PaBcYkXWyn=TmCROn61CGkEYD9qxob6hKGdD3sy-SyQ@mail.gmail.com>
<CALqxMTFv+nLo3phA2HS26F=r5+yGCOh=z8+Kub7GuC_bGVOfXg@mail.gmail.com>
<CALqxMTG7+MMN50VH9-Y++B1_DeBXTBKpkeA5dYT1EbVGZ1aYag@mail.gmail.com>
<CABsx9T3Xhu4n3LzjEjanbAnUr5UeG0DzY7HXchfOvEa+BNqakw@mail.gmail.com>
<CALqxMTGd1mB4Sra=ORV=d0y1v8KzUQnK8=MX2_MFP1NuMnPm+Q@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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: Mon, 29 Jun 2015 01:13:34 -0000
--Apple-Mail=_55A297D8-AD1A-4E32-ADB9-47086480D5A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
The Lightning network is essentially a contract negotiation scheme that =
rewards cooperation. Defection amounts to either broadcasting early or =
not responding to signature requests. If done right, either of these =
situations incurs a bigger cost to the uncooperative party than =
cooperation. This is why I say blockchains are like a fix to the =
prisoner=E2=80=99s dilemma.
The blockchain becomes essentially a dispute resolution mechanism and a =
way to anchor stuff. There=E2=80=99s no use case covered by the current =
method of =E2=80=9Cflood the entire network and confirm on blockchain=E2=80=
=9D that can=E2=80=99t be covered by a method of =E2=80=9Cparticipate in =
a contract which guarantees me payment on the blockchain if anyone is =
uncooperative but which rarely requires touching the blockchain=E2=80=9D =
methinks.
- Eric Lombrozo
> On Jun 28, 2015, at 3:07 PM, Adam Back <adam@cypherspace.org> wrote:
>=20
> On 28 June 2015 at 23:05, Gavin Andresen <gavinandresen@gmail.com> =
wrote:
>> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam@cypherspace.org> =
wrote:
>>>=20
>>> This is probably going to sound impolite, but I think it's =
pertinent.
>>>=20
>>> Gavin, on dwelling on the the fact that you appear to not understand
>>> the basics of the lightning network, I am a little alarmed about =
this
>>=20
>> If I don't see how switching from using the thousands of =
fully-validating
>> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is =
better in
>> terms of decentralization (or security, in terms of Sybil/DoS =
attacks),
>=20
> Its a source routed network, not a broadcast network. Fees are
> charged on channels so
> DoS is just a way to pay people a multiple of bandwidth cost.
>=20
> in terms of trustlessness Andrew Lapp explained it pretty well:
>> I don't mind a set of central authorities being part of an option IF =
the central authority
>> doesn't need to be trusted. On the blockchain, the larger miner is, =
the more you have
>> to trust them to not collude with anyone to reverse your payments or =
destroy the trust
>> in the system in some attack. On the Lightning network, a large hub =
can't steal my
>> money.
>>=20
>> I think most people share the sentiment that trustlessness is what =
matters and
>> decentralization is just a synonym for trustlessness when talking =
about the blockchain
>> and mining, however decentralization isn't necessarily synonymous =
with trustlessness
>> nor is centralization synonymous with trust-requiring when you're =
talking about
>> something else.
>=20
> Gavin wrote:
>> then I doubt other people do, either. You need to do a better job of =
explaining it.
>=20
> I gave it a go a couple of posts up. I didnt realise people here
> proposing mega-blocks were not paying attention to the whole lightning
> concept and detail.
>=20
> People said lots of things about how it's better to work on lightning,
> to scale algorithmically, rather than increasing block-size to
> dangerously centralising proportions.
> Did you think we were Gish Galloping you? We were completely serious.
>=20
> The paper is on http://lightning.network
>=20
> though it is not so clearly explained there, however Joseph is working
> on improving the paper as I understand it.
>=20
> Rusty wrote a high-level blog explainer: =
http://rusty.ozlabs.org/?p=3D450
>=20
> though I don't recall that he got into recirculation, negative fees
> etc. A good question
> for the lightning-dev mailing list maybe.
>=20
> http://lists.linuxfoundation.org/pipermail/lightning-dev/
>=20
> There are a couple of recorded presentation videos / podcasts from =
Joseph Poon.
>=20
> sf bitcoin dev presentation:
>=20
> https://www.youtube.com/watch?v=3D2QH5EV_Io0E
>=20
> epicenter bitcoin:
>=20
> https://www.youtube.com/watch?v=3DfBS_ieDwQ9k
>=20
> There's a related paper from Christian Decker "Duplex Micropayment =
Channels"
>=20
> =
http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-mic=
ropayment-channels.pdf
>=20
>> But even if you could convince me that it WAS better from a
>> security/decentralization point of view:
>=20
> We don't need to convince people, we just have to code it and
> demonstrate it, which people are working on.
>=20
> But Lightning does need a decentralised and secure Bitcoin network for
> anchor and reclaim transactions, so take it easy with the mega-blocks
> in the mean-time.
>=20
>> a) Lightning Network is nothing but a whitepaper right now. We are a =
long
>> way from a practical implementation supported by even one wallet.
>=20
> maybe you want to check in on
>=20
> https://github.com/ElementsProject/lightning
>=20
> and help code it.
>=20
> I expect we can get something running inside a year. Which kind of
> obviates the burning "need" for a schedule into the far future rising
> to 8GB with unrealistic bandwidth growth assumptions that will surely
> cause centralisation problems.
>=20
> For block-size I think it would be better to have a 2-4 year or one
> off size bump with policy limits and then re-evaluate after we've seen
> what lightning can do.
>=20
> I have been saying the same thing ad-nauseam for weeks.
>=20
>> b) The Lightning Network paper itself says bigger blocks will be =
needed even
>> if (especially if!) Lightning is wildly successful.
>=20
> Not nearly as big as if you tried to put the transactions it would
> enable on the chain, that's for sure! We dont know what that limit is
> but people have been imagining 1,000 or 10,000 transactions per anchor
> transaction. If micro-payments get popular many more.
>=20
> Basically users would park Bitcoins a on a hub channel instead of the
> blockchain. The channel can stay up indefinitely, and the user has
> assurances analogous to greenaddress time-lock mechanism
>=20
> Flexcap maybe a better solution because that allows bursting
> block-size when economically rational.
>=20
> Note that the time-locks with lightning are assumed to be relative
> CTLV eg using the mechanism as Mark Friedenbach described in a post
> here, and as implemented in the elements sidechain, so there is not a
> huge rush to reclaim funds. They can be spread out in time.
>=20
> If you want to scale Bitcoin - like really scale it - work on
> lightning. Lightning + a decentralised and secure Bitcoin, scales
> further and is more trustless than Bitcoin forced into centralisation
> via premature mega-blocks.
>=20
> To my mind a shorter, more conservative block-size increase to give a
> few years room is enough for now. We'll be in a better position to
> know what the right next step is after lightning is running.
>=20
> Something to mention is you can elide transactions before reclaiming.
> So long as the balancing transaction is correct, someone online can
> swap it for you with an equal balance one with less hops of
> intermediate payment flows.
>=20
>=20
> It's pretty interesting what you can do already. I'm fairly confident
> we're not finished algorithmically optimising it either. It's
> surprising how much new territory there is just sitting there
> unexplored.
>=20
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_55A297D8-AD1A-4E32-ADB9-47086480D5A0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVkJu5AAoJEJNAI64YFENUIxoQAK21Xz8lPLRhTfxp2fV5ci0h
JnFtqyOhKCH4tSL3K0X2WoYtolzUSRE5JrBNmYEtnIZjmp5vL9horwXmsZYo6/Qm
bHtI5I5/xt5wDFsKPQXEmE1T5TmjdxsFVB1wbfrUngKxNtAK2xdenl2iDL9xDIsg
RCCY1oi8tuRucsz35FkMyNh0zAAOkBcTrWAov+DYQXAZVv3KllaV27ktWN2ar/p0
Ul1G5Q0rytvtLIZQ/Qkm3Z9HYicyCbB7iQYCKCtdpjDziUfMQUGwlOGInG22If8r
CFs0aHyb7uBWwkokvma9Gkt3/nG6swQowyH+ZkeThl+yaZFeMWaAHHV6ezOElYsb
N4zvsA9bpiNe2BkxXpIEBzUks2PnUI7w8mkpc3hBoEW5AaYbvkkjXW07pquvIQEN
kNupWVspj9xiyoUYs/UwcosHjii8mxy8NFf29fJ0NtNR02MJC6Ojg1qdjqnZToR9
xX/6/BS5EtYnLqtyKTL1cpw8NCAcDxRF5/jyx+Clf07dC5BjFxRM+D0n4HAftKqk
/NQZflhUVRtyqx1gB7jNcjgLUuaHZu6QRthxCgsCjAJDT3qdsx/W03M7c8PiTxfv
9ZGuhMuLGYquTVKo3rZh6bHNWwe8aL1UogZi7EWWBjZZQ8PCSymc+Ygt/Duw7t7a
6QTjockEfg7BPLDtAaKh
=rAEj
-----END PGP SIGNATURE-----
--Apple-Mail=_55A297D8-AD1A-4E32-ADB9-47086480D5A0--
|