From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A27D0ACB for ; 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 ; Mon, 29 Jun 2015 00:59:44 +0000 (UTC) Received: by pactm7 with SMTP id tm7so95864688pac.2 for ; 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 In-Reply-To: Date: Sun, 28 Jun 2015 17:59:40 -0700 Message-Id: <2FEA7608-27D6-44C4-B521-091C061D5498@gmail.com> References: To: Adam Back 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >=20 > On 28 June 2015 at 23:05, Gavin Andresen = wrote: >> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back = 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--