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 DB8558B4 for ; Mon, 29 Jun 2015 01:45:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from uschroder.com (uschroder.com [74.142.93.202]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id A5807A7 for ; Mon, 29 Jun 2015 01:45:12 +0000 (UTC) Received: from [192.168.253.4] (cpe-74-132-161-228.kya.res.rr.com [74.132.161.228]) by uschroder.com (Postfix) with ESMTPSA id D293E22E43E07; Sun, 28 Jun 2015 21:45:12 -0400 (EDT) Message-ID: <5590A325.800@AndySchroder.com> Date: Sun, 28 Jun 2015 21:45:09 -0400 From: Andy Schroder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adam Back References: In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ktQPoa9UtTlDvSJCsOfXsn0TuIP5tjq4R" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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 01:45:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ktQPoa9UtTlDvSJCsOfXsn0TuIP5tjq4R Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Regarding privacy and the lightening network. Has this been well=20 addressed? I haven't seen much that leads me to believe there is. Only=20 options I see are to have many open payment channels, but that is still=20 limiting and inefficient, or require an extensive number of hops in your = payment route, but this is also limiting. Andy Schroder On 06/28/2015 06:07 PM, Adam Back wrote: > On 28 June 2015 at 23:05, Gavin Andresen wrot= e: >> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back wrot= e: >>> This is probably going to sound impolite, but I think it's pertinent.= >>> >>> 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= >> If I don't see how switching from using the thousands of fully-validat= ing >> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is bett= er in >> terms of decentralization (or security, in terms of Sybil/DoS attacks)= , > 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. > > 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 t= he central authority >> doesn't need to be trusted. On the blockchain, the larger miner is, th= e more you have >> to trust them to not collude with anyone to reverse your payments or d= estroy the trust >> in the system in some attack. On the Lightning network, a large hub ca= n't steal my >> money. >> >> I think most people share the sentiment that trustlessness is what mat= ters and >> decentralization is just a synonym for trustlessness when talking abou= t the blockchain >> and mining, however decentralization isn't necessarily synonymous with= trustlessness >> nor is centralization synonymous with trust-requiring when you're talk= ing about >> something else. > Gavin wrote: >> then I doubt other people do, either. You need to do a better job of e= xplaining it. > 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. > > 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. > > The paper is on http://lightning.network > > though it is not so clearly explained there, however Joseph is working > on improving the paper as I understand it. > > Rusty wrote a high-level blog explainer: http://rusty.ozlabs.org/?p=3D4= 50 > > though I don't recall that he got into recirculation, negative fees > etc. A good question > for the lightning-dev mailing list maybe. > > http://lists.linuxfoundation.org/pipermail/lightning-dev/ > > There are a couple of recorded presentation videos / podcasts from Jose= ph Poon. > > sf bitcoin dev presentation: > > https://www.youtube.com/watch?v=3D2QH5EV_Io0E > > epicenter bitcoin: > > https://www.youtube.com/watch?v=3DfBS_ieDwQ9k > > There's a related paper from Christian Decker "Duplex Micropayment Chan= nels" > > http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-= micropayment-channels.pdf > >> But even if you could convince me that it WAS better from a >> security/decentralization point of view: > We don't need to convince people, we just have to code it and > demonstrate it, which people are working on. > > 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. > >> a) Lightning Network is nothing but a whitepaper right now. We are a l= ong >> way from a practical implementation supported by even one wallet. > maybe you want to check in on > > https://github.com/ElementsProject/lightning > > and help code it. > > 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. > > 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. > > I have been saying the same thing ad-nauseam for weeks. > >> b) The Lightning Network paper itself says bigger blocks will be neede= d even >> if (especially if!) Lightning is wildly successful. > 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. > > 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 > > Flexcap maybe a better solution because that allows bursting > block-size when economically rational. > > 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. > > 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. > > 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. > > 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. > > > 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. > > Adam > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --ktQPoa9UtTlDvSJCsOfXsn0TuIP5tjq4R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJVkKMlAAoJEDT679stRBhrmjIH/1QcjP+0HAK48wxS8zaQugCM Sd3NmeCUIFfJJFbyauKkOc2DlR2ROyEd0brSc/8u0Zxw7GWM2GyS17a4AAo5Upuc C8AEq4BkTvn143qzobpTnojSKHQqBBPUgyDvd71f4zu7M4qG89izW2vP3MtigFpX PVOr5/c/sJXY5sRZVoJJIWzX+oYLuq7AAXvadrF3PqWOVe55l4uaQ7YjcYwnTjDd qQclLG37uldhCeuqcGz/3aP9jmL5cJ8JHsk4eg+elfsY3L8Yja5BqZ2Vdr6iVenJ 4BpmDveJmcOv+fBLRwy6B4EDZg70zC1pGEeI1KSh3lc6yeAB/2wecHv0FrwJNQU= =CDKr -----END PGP SIGNATURE----- --ktQPoa9UtTlDvSJCsOfXsn0TuIP5tjq4R--