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 EB71CAC2 for ; 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 ; Mon, 29 Jun 2015 01:13:33 +0000 (UTC) Received: by pdbci14 with SMTP id ci14so106581110pdb.2 for ; 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 In-Reply-To: Date: Sun, 28 Jun 2015 18:13:29 -0700 Message-Id: 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 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 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=_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--