+Return-Path: <lapp0@purdue.edu>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 46633ACC

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Sun, 28 Jun 2015 19:37:23 +0000 (UTC)

+X-Greylist: delayed 00:11:42 by SQLgrey-1.7.6

+Received: from mailhub248.itcs.purdue.edu (mailhub248.itcs.purdue.edu

+ [128.210.5.248])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCDBFE7

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Sun, 28 Jun 2015 19:37:22 +0000 (UTC)

+Received: from [192.168.1.189] (c-50-165-111-123.hsd1.in.comcast.net

+ [50.165.111.123]) (authenticated bits=0)

+ by mailhub248.itcs.purdue.edu (8.14.4/8.14.4/mta-auth.smtp.purdue.edu)

+ with ESMTP id t5SJPdAB014289

+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT)

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Sun, 28 Jun 2015 15:25:40 -0400

+Message-ID: <5590498D.6010406@purdue.edu>

+Date: Sun, 28 Jun 2015 15:22:53 -0400

+From: Andrew Lapp <lapp0@purdue.edu>

+User-Agent: Mozilla/5.0 (X11; Linux x86_64;

+ rv:31.0) Gecko/20100101 Icedove/31.5.0

+MIME-Version: 1.0

+To: bitcoin-dev@lists.linuxfoundation.org

+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>

+In-Reply-To: <CABsx9T3PaBcYkXWyn=TmCROn61CGkEYD9qxob6hKGdD3sy-SyQ@mail.gmail.com>

+Content-Type: text/plain; charset=windows-1252; format=flowed

+Content-Transfer-Encoding: 7bit

+X-PMX-Version: 6.0.2.2308539

+X-PerlMx-URL-Scanned: Yes

+X-PerlMx-Virus-Scanned: Yes

+X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,

+ RP_MATCHES_RCVD autolearn=ham version=3.3.1

+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on

+ smtp1.linux-foundation.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 19:37:23 -0000

+

+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.

+

+-Andrew Lapp

+

+On 06/28/2015 01:29 PM, Gavin Andresen wrote:

+> I can see how payment channels would work between big financial

+> institutions as a settlement layer, but isn't that exactly the

+> centralization concern that is making a lot of people worried about

+> increasing the max block size?

+

+