path: root/1b/f0fa1d3e8fd426544bd821cb41e0bd4064553a

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 A27D0ACB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jun 2015 00:59:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com
	[209.85.220.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB7441C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jun 2015 00:59:44 +0000 (UTC)
Received: by pactm7 with SMTP id tm7so95864688pac.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 17:59:44 -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=GwSwiOYghy4ufCtBtjMqlmrmL9+DNAIVgBBmPK+vUKU=;
	b=GD1pqTaV2IdY6ySADR5n5QyWNz9jO1/CcFfCYvtcSzOgZ6G8g0tT7YbjOXY25NDBrk
	x1SeylA4oGd6XWOQHn/5pnIFuTJ05j0EtSMP5M9QMG41ShDkV32+lRGslMYpm+5ISder
	EPr36s5bZs+Kntj+DF7A6/IYWiy6MSl68wFK5PAPsHGOdk48P/B2na75jvEAjr/hU3N9
	wML8fAmPoglp/kdxg091xS3LbEgaBdtyk0PHTLOusHXmIMYNyNzMfNZNqFfCthtWwCKb
	wor30OSo3WjeArOa4t+IVeS9GgSGVJdAFKWFTnWA1GhXGgE6bIQgnr0JP6+Qn3YvxQB9
	mf1Q==
X-Received: by 10.68.203.197 with SMTP id ks5mr26360853pbc.51.1435539584379;
	Sun, 28 Jun 2015 17:59:44 -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
	gy3sm40143124pbb.42.2015.06.28.17.59.42
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sun, 28 Jun 2015 17:59:43 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_468278D3-B8A8-4A41-B686-C1CCE106F262";
	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 17:59:40 -0700
Message-Id: <2FEA7608-27D6-44C4-B521-091C061D5498@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 00:59:45 -0000


--Apple-Mail=_468278D3-B8A8-4A41-B686-C1CCE106F262
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

There=E2=80=99s no question that a flooding mesh network requiring =
global consensus for every transactions is not the way. It=E2=80=99s =
also clear that a routable protocol capable of compensating hubs is =
basically the holy grail.

So what=E2=80=99s there to discuss?

- Eric

> 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=_468278D3-B8A8-4A41-B686-C1CCE106F262
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

iQIcBAEBCgAGBQJVkJh9AAoJEJNAI64YFENUho4QALYTDSBjz+hyEhGZRe2i+IYL
gPaHmc0Oc4GGAxZOY+S7UTUfbPsIB4av22HTCgzAT3q6p8Q/6OwyyqNpJoxUa1Qu
944c9CpCQFTpMpl3lvrRXpReTqU3pQg9ZfqzH+7vmqjEoT+/+MLV7gpRK9169OIs
MQExcmLKqIYFNsMVdqSnd5utZT8YW/hZss+oZfS4bTYPZ2kw2SQtKcn7hl6A6KBZ
94oVkg3GrTkBXf6+6QIeCzJE9+TzWEol2bPa2w3rkSUgpjosmvlD3eQsE6cIdl5B
NMSn5rYoCCOglGw4mk15l9iWZ3yfWJBfL5gSIiWDOR3JykyR2N1x4NZ9O7PShJ/M
gua6OlePRO5V3fs8lQpL+1pekescqx94ndUmXcPtiSKpqb4UHwEJ6Mp3U7FfXkhv
DpL23l3l3TYbh0g82i2hzEmUKFermStAyFN3vwDG77aMBesVOCHM4RLZa+PF9VXj
fadGRGxbIwaLJ0CSZdzOJ0tBZ0tNLvfKyZfKqBcp4q/Yyui6IJRKKCHC4/MKimZT
eJbhdw9C4FEGcHWNYRaIXYuGNzoGDmDIiuh0zyBjDi5/KZaV1J9N3Sao4xepjzCi
oL2U8pX+UvwxgYLi7l2Yx4pIrM60Prw34Qd0r/lc0J2uKMCPXHVD6fPTTeABjbWV
6YRL/bVeePda1CzxrEoq
=XUV5
-----END PGP SIGNATURE-----

--Apple-Mail=_468278D3-B8A8-4A41-B686-C1CCE106F262--