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 1F5C5405 for ; Fri, 31 Jul 2015 10:16:48 +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 F092FEE for ; Fri, 31 Jul 2015 10:16:46 +0000 (UTC) Received: by ioii16 with SMTP id i16so80744972ioi.0 for ; Fri, 31 Jul 2015 03:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3vxxKpGRqLr/ki9mCTgQGyeCbUoWt2z0v5kby2ZBLAE=; b=pm+X5IogYfIvLtj1yuDlqqUFaxTuD2t0Mk2BScGp0pPtOyDjWUfPcqlc2gBP6b3+2o uNu+PJrUjFCJOcLpMSINhQESlsGmZhomYDm75MJrYCKGPLeg3Ddpp7YupX3+vRK/zwQC 2LASyllTBSghOs3LJ9Iq7q4/kEG5kFhKV1RwM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3vxxKpGRqLr/ki9mCTgQGyeCbUoWt2z0v5kby2ZBLAE=; b=GLq5EeMiE8DOvA+PeoR2ts05AcrOg1f+p59QZC1MF8Ke02xzUCkNWDvMkyY451PshQ uHRbDxitbRUmzDtkPGknJFrIC2JOghaaZlz7V3KjewPBCdSdCBzcZt59F2+1ICydFrDZ Iu6zvuJhxpujqa5dFQNAWB79Zn5lkwhTbY/PjuIBtAEwL+O+UEje3z7dw81dkGjz06H6 TR4WQyo7URXuuB+STsfXGFftKbrwWU9FcvtMF9f911bk8jAvYdbslteWJn2Au241fSCK RijpFZnW00wszAgf1ZqSy5NYcbnFL533KwR32HGwml2pRwGOMWG3qNEWUeE5p6BioABS xWFw== X-Gm-Message-State: ALoCoQkcFwBbpGAiJ+tR5AwP+MCzJKGFYTarH4shdKJ7Fn0KHwVtZ3mEjL6k1JmlsG4ZB2p51QCf MIME-Version: 1.0 X-Received: by 10.107.135.193 with SMTP id r62mr3198481ioi.29.1438337806445; Fri, 31 Jul 2015 03:16:46 -0700 (PDT) Received: by 10.50.108.111 with HTTP; Fri, 31 Jul 2015 03:16:46 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Jul 2015 12:16:46 +0200 Message-ID: From: Mike Hearn To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a113eceb2054cb8051c291e9f X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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] 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, 31 Jul 2015 10:16:48 -0000 --001a113eceb2054cb8051c291e9f Content-Type: text/plain; charset=UTF-8 I agree with Gavin - whilst it's great that a Blockstream employee has finally made a realistic proposal (i.e. not "let's all use Lightning") - this BIP is virtually the same as keeping the 1mb cap. > Well, centralization of mining is already terrible. I see no reason why we > should encourage making it worse. > Centralization of mining has been a continual gripe since Slush first invented pooled mining. There has never been a time after that when people weren't talking about the centralisation of mining, and back then blocks were ~10kb. I see constant assertions that node count, mining centralisation, developers not using Bitcoin Core in their own businesses etc is all to do with block sizes. But nobody has shown that. Nobody has even laid the groundwork for that. Verifying blocks takes milliseconds and downloading them takes seconds everywhere except, apparently, China: this resource usage is trivial. Yet developers, miners and users even outside of China routinely delegate validation to others. Often for quite understandable technical reasons that have nothing to do with block sizes. So I see no reason why arbitrarily capping the block size will move the needle on these metrics. Trying to arrest the growth of Bitcoin for everyone won't suddenly make Bitcoin-Qt a competitive wallet, or make service devs migrate away from chain.com, or make merchants stop using BitPay. We need to accept that, and all previous proposals I've seen don't seem to > do that. > I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth you're right, some use cases will be priced out. I initiated the micropayment channels project (along with Matt, tip of the hat) specifically to optimise a certain class of transactions. Even with 8mb+ blocks, there will still be a need for micropayment channels, centralised exchange platforms and other forms of off chain transaction. If Bitcoin needs to support a large scale, it already failed. > It hasn't even been tried. The desperately sad thing about all of this is that there's going to be a fork, and yet I think most of us agree on most things. But we don't agree on this. Bitcoin can support a large scale and it must, for all sorts of reasons. Amongst others: 1. Currencies have network effects. A currency that has few users is simply not competitive with currencies that have many. There's no such thing as a settlement currency for high value transactions only, as evidenced by the ever-dropping importance of gold. 2. A decentralised currency that the vast majority can't use doesn't change the amount of centralisation in the world. Most people will still end up using banks, with all the normal problems. You cannot solve a problem by creating a theoretically pure solution that's out of reach of ordinary people: just ask academic cryptographers! 3. Growth is a part of the social contract. It always has been. The best quote Gregory can find to suggest Satoshi wanted small blocks is a one sentence hypothetical example about what *might* happen if Bitcoin users became "tyrannical" as a result of non-financial transactions being stuffed in the block chain. That position makes sense because his scaling arguments assuming payment-network-sized traffic and throwing DNS systems or whatever into the mix could invalidate those arguments, in the absence of merged mining. But Satoshi did invent merged mining, and so there's no need for Bitcoin users to get "tyrannical": his original arguments still hold. 4. All the plans for some kind of ultra-throttled Bitcoin network used for infrequent transactions neglect to ask where the infrastructure for that will come from. The network of exchanges, payment processors and startups that are paying people to build infrastructure are all based on the assumption that the market will grow significantly. It's a gamble at best because Bitcoin's success is not guaranteed, but if the block chain cannot grow it's a gamble that is guaranteed to be lost. So why should anyone go through the massive hassle of setting up exchanges, without the lure of large future profits? 5. Bitcoin needs users, lots of them, for its political survival. There are many people out there who would like to see digital cash disappear, or be regulated out of existence. They will argue for that in front of governments and courts .... some already are. And if they're going to lose those arguments, the political and economic damage of getting rid of Bitcoin must be large enough to make people think twice. That means it needs supporters, it needs innovative services, it needs companies, and it needs legal users making legal payments: as many of them as possible. If Bitcoin is a tiny, obscure currency used by drug dealers and a handful of crypto-at-any-cost geeks, the cost of simply banning it outright will seem trivial and the hammer will drop. There won't be a large scale payment network OR a high-value settlement network. And then the world is really screwed, because nobody will get a second chance for a very long time. --001a113eceb2054cb8051c291e9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Gavin - whilst it's great that a Blockstream employee has= finally made a realistic proposal (i.e. not "let's all use Lightn= ing") - this BIP is virtually the same as keeping the 1mb cap.

Well, centralization of mining = is already terrible. I see no reason why we should encourage making it wors= e.

Centralization of mining has been a continual gripe= since Slush first invented pooled mining. There has never been a time afte= r that when people weren't talking about the centralisation of mining, = and back then blocks were ~10kb.=C2=A0

I see const= ant assertions that node count, mining centralisation, developers not using= Bitcoin Core in their own businesses etc is all to do with block sizes. Bu= t nobody has shown that. Nobody has even laid the groundwork for that. Veri= fying blocks takes milliseconds and downloading them takes seconds everywhe= re except, apparently, China: this resource usage is trivial.=C2=A0

Yet developers, miners and users even outside of China ro= utinely delegate validation to others. Often for quite understandable techn= ical reasons that have nothing to do with block sizes.

=
So I see no reason why arbitrarily capping the block size will move th= e needle on these metrics. Trying to arrest the growth of Bitcoin for every= one won't suddenly make Bitcoin-Qt a competitive wallet, or make servic= e devs migrate away from chain.com, or mak= e merchants stop using BitPay.

We need to accept that, and all previous proposals I&= #39;ve seen don't seem to do that.

I think that= 9;s a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth you're righ= t, some use cases will be priced out. I initiated the micropayment channels= project (along with Matt, tip of the hat) specifically to optimise a certa= in class of transactions. Even with 8mb+ blocks, there will still be a need= for micropayment channels, centralised exchange platforms and other forms = of off chain transaction.

If Bitcoin needs to support a large scale, it already fail= ed.

It hasn't even been tried.=C2=A0

The desperately sad thing about all of this is that th= ere's going to be a fork, and yet I think most of us agree on most thin= gs.=C2=A0 But we don't agree on this.=C2=A0

Bi= tcoin can support a large scale and it must, for all sorts of reasons. Amon= gst others:
  1. Currencies have network effects. A currency t= hat has few users is simply not competitive with currencies that have many.= There's no such thing as a settlement currency for high value transact= ions only, as evidenced by the ever-dropping importance of gold.

  2. A decentralised currency that the vast majority can't use doe= sn't change the amount of centralisation in the world. Most people will= still end up using banks, with all the normal problems. You cannot solve a= problem by creating a theoretically pure solution that's out of reach = of ordinary people: just ask academic cryptographers!


  3. G= rowth is a part of the social contract. It always has been.=C2=A0

    Th= e best quote Gregory can find to suggest Satoshi wanted small blocks is a o= ne sentence hypothetical example about what might happen if Bitcoin = users became "tyrannical" as a result of non-financial transactio= ns being stuffed in the block chain. That position makes sense because his = scaling arguments assuming payment-network-sized traffic and throwing DNS s= ystems or whatever into the mix could invalidate those arguments, in the ab= sence of merged mining. But Satoshi did invent merged mining, and so there&= #39;s no need for Bitcoin users to get "tyrannical": his original= arguments still hold.


  4. All the plans for some kind of u= ltra-throttled Bitcoin network used for infrequent transactions neglect to = ask where the infrastructure for that will come from. The network of exchan= ges, payment processors and startups that are paying people to build infras= tructure are all=C2=A0based on the assumption that the market will grow sig= nificantly. It's a gamble at best because Bitcoin's success is not = guaranteed, but if the block chain cannot grow it's a gamble that is gu= aranteed to be lost.

    So why should anyone go through the massive has= sle of setting up exchanges, without the lure of large future profits?
    <= br>
  5. Bitcoin needs users, lots of them, for its political surviv= al. There are many people out there who would like to see digital cash disa= ppear, or be regulated out of existence. They will argue for that in front = of governments and courts .... some already are. And if they're going t= o lose those arguments, the political and economic damage of getting rid of= Bitcoin must be large enough to make people think twice. That means it nee= ds supporters, it needs innovative services, it needs companies, and it nee= ds legal users making legal payments: as many of them as possible.

    I= f Bitcoin is a tiny, obscure currency used by drug dealers and a handful of= crypto-at-any-cost geeks, the cost of simply banning it outright will seem= trivial and the hammer will drop. There won't be a large scale payment= network OR a high-value settlement network. And then the world is really s= crewed, because nobody will get a second chance for a very long time.
    6. <= /ol>


--001a113eceb2054cb8051c291e9f--