Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F0D548C8 for ; Fri, 7 Aug 2015 18:10:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2B2E7213 for ; Fri, 7 Aug 2015 18:10:50 +0000 (UTC) Received: by ioii16 with SMTP id i16so119336928ioi.0 for ; Fri, 07 Aug 2015 11:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IluwGD6SxCBUgVx5aFOizG2tPNVuA3GZ77W6iJ7py50=; b=Mnv+MZekrdSwE7uPBA+ycZ7lIfABAuD6MXxIJ2OFWYS/kFkA2nRu2pUpfveKgxBpI8 UplST+zaQ16qAb6k47WxBMjIDkuOg/2sp0dTPhdgTkhB2yWfd7kRcCJNB/gsU7xfHXm9 +kwFsG884+1FZXCJEseaHs+34xepRU4/EIrfN/ZSt+la5rPpqeKd9GH715wYsI/eEFDx +h7pGaklAj4CBhOcZ4TZ1bNOMiTdL0kZ2Qqo05ft7BRuxTO/Inkj5Mg2mGjXFh0/A4xU XrryCau747MAw2n0MRpKeG/aCboNTq52xtSoS5fHLBtiq84Vr3LEgsYCgkvBu1cpvoip A6FA== MIME-Version: 1.0 X-Received: by 10.107.37.142 with SMTP id l136mr9850205iol.126.1438971049582; Fri, 07 Aug 2015 11:10:49 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Fri, 7 Aug 2015 11:10:48 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Fri, 7 Aug 2015 11:10:48 -0700 (PDT) In-Reply-To: References: <1542978.eROxFinZd4@coldstorage> Date: Fri, 7 Aug 2015 20:10:48 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a1140269a40b14b051cbc8e17 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Subject: Re: [bitcoin-dev] Fwd: Block size following technological growth 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: Fri, 07 Aug 2015 18:10:51 -0000 --001a1140269a40b14b051cbc8e17 Content-Type: text/plain; charset=UTF-8 On Aug 7, 2015 7:50 PM, "Gavin Andresen" wrote: > > > On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> If the incentives for running a node don't weight up against the cost/difficulty using a full node yourself for a majority of people in the ecosystem, I would argue that there is a problem. As Bitcoin's fundamental improvement over other systems is the lack of need for trust, I believe that with increased adoption should also come an increased (in absolute terms) incentive for people to use a full node. I'm seeing the opposite trend, and that is worrying IMHO. > > > Are you saying that unless the majority of people in the ecosystem decide to trust nothing but the genesis block hash (decide to run a full node) there is a problem? I shouldn't have said majority, sorry. But I do believe that as the odds at stake in the system go up, so should those who take an interest in verifying. That doesn't seem to be the case, and is a problem, where that is a result of the block chain size or not. > If so, then we do have a fundamental difference of opinion, but I've misunderstood how you think about trust/centralization/convenience tradeoffs in the past. > > I believe people in the Bitcoin ecosystem will choose different tradeoffs, and I believe that is OK-- people should be free to make those tradeoffs. I agree. Though I believe that the blockchain itself cannot offer many tradeoffs, and by trying to make it scale we hurt the whole system. The place to introduce tradeoffs is in layers on top - there you can build systems with various levels of trust without hurting others. > And given that the majority of people in the ecosystem were deciding that using a centralized service or an SPV-level-security wallet was better even two or three years ago when blocks were tiny (I'd have to go back and dig up number-of-full-nodes and number-of-active-wallets at the big web-wallet providers, but I bet there were an order of magnitude more people using centralized services than running full nodes even back then). That's inevitable, I'm sure. > I firmly believe that block size has very little to do with the decision to run a full node or not. Within certain limits, maybe not. Within certain limits, maybe it also does not incentivize trusted miner setups like SPV mining (which hurt the security of SPV nodes tremendously). But if the reason for increasing is because you fear a change of economics, then it means you prefer not dealing with that change. I believe you prefer not dealing with it ever, and would rather have a system where as much as possible happens on-chain, even when we unknowingly go beyond those limits. I think we don't do the ecosystem a service by promising that such a future is possible without compromises. So, I think the block size should follow technological evolution, and not reenforce the belief that the block size should follow demand. There will always be demand, and we should learn to deal with it. -- Pieter --001a1140269a40b14b051cbc8e17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 7, 2015 7:50 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.org> wrote:
>>
>> If the incentives for running a node don't weight up against t= he cost/difficulty using a full node yourself for a majority of people in t= he ecosystem, I would argue that there is a problem. As Bitcoin's funda= mental improvement over other systems is the lack of need for trust, I beli= eve that with increased adoption should also come an increased (in absolute= terms) incentive for people to use a full node. I'm seeing the opposit= e trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem dec= ide to trust nothing but the genesis block hash (decide to run a full node)= there is a problem?

I shouldn't have said majority, sorry. But I do believe = that as the odds at stake in the system go up, so should those who take an = interest in verifying. That doesn't seem to be the case, and is a probl= em, where that is a result of the block chain size or not.

> If so, then we do have a fundamental difference of opin= ion, but I've misunderstood how you think about trust/centralization/co= nvenience tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different tradeo= ffs, and I believe that is OK-- people should be free to make those tradeof= fs.

I agree. Though I believe that the blockchain itself cannot = offer many tradeoffs, and by trying to make it scale we hurt the whole syst= em. The place to introduce tradeoffs is in layers on top - there you can bu= ild systems with various levels of trust without hurting others.

> And given that the majority of people in the ecosystem = were deciding that using a centralized service or an SPV-level-security wal= let was better even two or three years ago when blocks were tiny (I'd h= ave to go back and dig up number-of-full-nodes and number-of-active-wallets= at the big web-wallet providers, but I bet there were an order of magnitud= e more people using centralized services than running full nodes even back = then).

That's inevitable, I'm sure.

> I firmly believe that block size has very little to do = with the decision to run a full node or not.

Within certain limits, maybe not. Within certain limits, may= be it also does not incentivize trusted miner setups like SPV mining (which= hurt the security of SPV nodes tremendously).

But if the reason for increasing is because you fear a chang= e of economics, then it means you prefer not dealing with that change. I be= lieve you prefer not dealing with it ever, and would rather have a system w= here as much as possible happens on-chain, even when we unknowingly go beyo= nd those limits. I think we don't do the ecosystem a service by promisi= ng that such a future is possible without compromises.

So, I think the block size should follow technological evolu= tion, and not reenforce the belief that the block size should follow demand= . There will always be demand, and we should learn to deal with it.

--
Pieter

--001a1140269a40b14b051cbc8e17--