diff options
| author | Eric Lombrozo <elombrozo@gmail.com> | 2015-06-28 18:13:29 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-29 01:13:33 +0000 |
| commit | c52e0a9a9a1a08958e1cbefdf4105e9de2926666 (patch) | |
| tree | 6a5b0a2e41f92bf677f61e67578d9629abe941ee | |
| parent | fcba71a133b65dd3de5ed7f5b61e40aa967c9e97 (diff) | |
| download | pi-bitcoindev-c52e0a9a9a1a08958e1cbefdf4105e9de2926666.tar.gz pi-bitcoindev-c52e0a9a9a1a08958e1cbefdf4105e9de2926666.zip | |
Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
| -rw-r--r-- | 36/f35777677e19cc05d4df1fcecf91eaabe39bfb | 297 |
1 files changed, 297 insertions, 0 deletions
diff --git a/36/f35777677e19cc05d4df1fcecf91eaabe39bfb b/36/f35777677e19cc05d4df1fcecf91eaabe39bfb new file mode 100644 index 000000000..24a634667 --- /dev/null +++ b/36/f35777677e19cc05d4df1fcecf91eaabe39bfb @@ -0,0 +1,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-- + |