path: root/0e/c71fec2eebbaf8f42e6b5e498aaf88e6c3c4ae

Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 19099B1B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 22:12:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E8AC8E5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 22:12:43 +0000 (UTC)
Received: from mail-qc0-f182.google.com ([209.85.216.182]) by
	mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id
	0MPnfw-1Z5T6o1B7y-004yxQ for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 Jun 2015 00:07:12 +0200
Received: by qcbcf1 with SMTP id cf1so39339210qcb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 15:07:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.96.38 with SMTP id j35mr15690855qge.43.1435529231638;
	Sun, 28 Jun 2015 15:07:11 -0700 (PDT)
Received: by 10.96.28.39 with HTTP; Sun, 28 Jun 2015 15:07:11 -0700 (PDT)
In-Reply-To: <CABsx9T3Xhu4n3LzjEjanbAnUr5UeG0DzY7HXchfOvEa+BNqakw@mail.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>
Date: Mon, 29 Jun 2015 00:07:11 +0200
Message-ID: <CALqxMTGd1mB4Sra=ORV=d0y1v8KzUQnK8=MX2_MFP1NuMnPm+Q@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:PRvx72oELDYxTJbsTDfy9gyo0sLdpHsDBuLuVtgss1L0XZL9BuT
	kk+VQJjkAM3GaCaZMzvCZP4strbx9N3R0U1ZGXY/lv0auiyd/FVY8YWJsLOKfzlMn6WKR/O
	SY944hyPSCZQTc3Cjfvfkuno/+UPCAH8i0Cr+GJeqSUwq94mNAgT13foRwSqA0md3e0D/dl
	a14eUcsRVtDdb5QHdeQGQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:A3jlyPnt7C8=:wCzzA1cvbN12cPjMEjwAKV
	Lq5UXdDyyQwM4PhMWMHjWOsZ44/U2iN2L4psRfN6qJioNtfH7iEPakH71lXz3EcGSf8Glx7/P
	vSQrgB148BVOSyVNb0/ofhhd+aIEPKipKC2eEzTuibDHM55K0T0WMLcmq28IhR+AMCDIwi1+4
	PurhLU4twkmqdHOSOWqrqJrw/9Fvk/L6tMhCGz8uhjWbdybspic49t8AHOiuD31wouF6rrfrW
	QJFZhZq0y0hcuPvC1dRLHVBlT3FgzW48/w81BTl6ZgXHyA1O/8d6wt5sdTag40RCrpkW5TFja
	fWJnCYjUq/GmOR0+nLuoauBDxBXwR9CFbL5suNLlUKF2sVou9rGGLV0JrUFKhY53MXFPp5out
	+h88eYPEfCN76ResxTW9Har1ybQbh/AVu26Y3WHB4CQtP7JpiyA1iB/Ji9y26ubCYxKChO6Oh
	2ooeI3yzd/74NoFJs5Yg2gkE6sVKgvrozNIs/dJP2kk3/ksmQLIzboFF67FBCfaWgVUzWahXd
	+E4HmSPUA2p8gx0Rm22XSo9UPXLDIPwnmmDUPXlkh3hBOC88FUwi45ZqPUf0WlSz/zLUpjeFT
	QXOlVdBIjDFWUqlrrAwWxRcjTkB5r3inGImCvY2+wtkbTgtPg9VpivFQaLOriHElw8MpC0sAQ
	extTSA1OhDO++AZfzSeuxREicBgv1FRNTVwRykAjHp6V3Uw==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	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: Sun, 28 Jun 2015 22:12:45 -0000

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:
>>
>> 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-validating
> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better 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 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.
>
> 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.

Gavin wrote:
> then I doubt other people do, either. You need to do a better job of explaining 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=450

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 Joseph Poon.

sf bitcoin dev presentation:

https://www.youtube.com/watch?v=2QH5EV_Io0E

epicenter bitcoin:

https://www.youtube.com/watch?v=fBS_ieDwQ9k

There's a related paper from Christian Decker "Duplex Micropayment Channels"

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 long
> 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 needed 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