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 F2A8F279 for ; Fri, 7 Aug 2015 00:37:20 +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 12DE215D for ; Fri, 7 Aug 2015 00:37:20 +0000 (UTC) Received: by iodd187 with SMTP id d187so97758232iod.2 for ; Thu, 06 Aug 2015 17:37:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=dK+zQCqsjzGpCgdFqVUQG5mVN0c4NySXrMiX/Wakhfo=; b=Ez0w8bJuqJdGGFP+Ee5Pvv7uzL+AQj3Xcdf9E3y6XRf4IxD10GIN5aJwqMLHCStp3/ 2tXXQgtUBwKbTw0EEb5yc2RKFd1BI2VXqVCLyBU0vEZWwhnjSrG4L2AROVZjljnfkDxr kBY6OABgLpqj1XReW45A2YuPQkJuxJUVVfb+JxVXLEd+VQx4iKSlli664z4SmqsBVchT uEpKV54tN/UAr8zMi6V4pEdUFcuzYyO31gIgDbHwrbLzLcbBY3fb+D66zi5QT0D0NwiO 70qqP2642noY10X2kcjjJ8WeB/t5R5l/ga7CJVP+F1Y6n/MpaUG5Sxeac/+4fEO8t0Tu 7X1A== X-Gm-Message-State: ALoCoQmIzalrGO+ykb0aohVEsKN4HAvSiBf8eirmHiDeA+LRRPz/9TgrWBtuNdWeKGCAAjXdAVie X-Received: by 10.107.166.71 with SMTP id p68mr5787147ioe.67.1438907839482; Thu, 06 Aug 2015 17:37:19 -0700 (PDT) Received: from Williams-MBP (c-73-34-122-98.hsd1.co.comcast.net. [73.34.122.98]) by smtp.gmail.com with ESMTPSA id m134sm5725134ioe.42.2015.08.06.17.37.17 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Aug 2015 17:37:18 -0700 (PDT) Date: Thu, 6 Aug 2015 18:37:16 -0600 From: Will To: Pieter Wuille via bitcoin-dev , Dave Scotese , Pieter Wuille Message-ID: In-Reply-To: References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55c3fdbc_4727356_180e" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Wrapping up the block size debate with voting 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 00:37:21 -0000 --55c3fdbc_4727356_180e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think the key is comity and humility in terms of being honest about our= inability to predict future trends in a meaningful way while passing thr= ough scrutiny coming from divergent perspectives. =C2=A08MB + 40% annuall= y (at whatever increase frequency is preferred, at coinbase halvings seem= s most ideal) is the proposal to use. What if 40% is too fast=3F =C2=A0=C2=A0 If 40% turns out to be excessive, miners have a built in incentive to cap= their blocks at a lower amount that meets the supply / demand equilibriu= m vs. the price of bitcoin trading on the free market. =C2=A0 The key her= e is to understand =E2=80=9Cprice of bitcoin on the free market=E2=80=9D.= =C2=A0Most developers don=E2=80=99t understand free market economics bey= ond gambling, which is a good bit of the problem here. =C2=A0 Bottom line is, miners directly benefit from higher bitcoin prices when d= enominated in other currencies. =C2=A0This fact will naturally limit exce= ssive growth of blk*.dat. size, because if the storage requirements for b= itcoin grow out of reach of amateurs, it will lead to excessive centraliz= ation and capture by powerful interests, which would threaten to convert = bitcoin to a form of sovereign currency and kill free demand for bitcoin = (and tank the price). =C2=A0Miners don=E2=80=99t want that without some o= ther body paying them to make econonically distorted decisions. =C2=A0The= y will limit the size themselves if they see this as an emerging threat. = =C2=A0It=E2=80=99s in their best interests and will keep them in business= longer. Now, is there a risk that some excessively well funded entity could artif= icially inflate the price of bitcoin while this bribing miners to let blk= *.dat size grow out of hand (distorting miner economics) in some sort of = =E2=80=9Csubsidies for increased liquidity=E2=80=9D corruption scheme=3F = =C2=A0No there isn=E2=80=99t, because we are going to have a cap on the s= ize that is reasonable enough that we know it won=E2=80=99t force out any= amateurs for at least 5 years, and likely longer. What if 40% is too slow=3F That=E2=80=99s a problem anyone who actually owns bitcoin would like to h= ave. =C2=A0We=E2=80=99ll gladly support an increase in the rate if demand= supports it later with a subsequent change. =C2=A0We=E2=80=99ll have to = do this eventually anyway when SHA256 and RIPEMD160 exhibit collisions, o= r some other non-self imposed existential threat rears its head. Long game Now, this entire scheme is predicated on the price going higher over the = extended term. =C2=A0I would argue that if we are doing a good job, the p= rice should go higher. =C2=A0Isn=E2=80=99t that the best barometer of per= formance=3F =C2=A0Demand for the scarce units inside the protocol denomin= ated in other currencies=3F 8MB is 1MB + 40% a year from January 2009 to today. =C2=A040% a year is a= s good as we are going to get in terms of our extrapolated estimation of = future ability to host full nodes. =C2=A0Anything else is overengineering= something we can=E2=80=99t predict anyway. =C2=A0Any arguments against t= his setting and rate of growth that aren=E2=80=99t exclusively focused on= the computer science side of the debate are misguided at best, and corru= pted by competing incentives at worst. =C2=A0This is because it=E2=80=99s= not possible to predict the future any better than using an extrapolatio= n of the past, which is exactly what 8MB + 40% represents. So TLDR=3F =C2=A0Go with 8MB + 40% annually and we will cross any (likely= imaginary) bridges when we come to them down the road. Will =46rom:=C2=A0Pieter Wuille via bitcoin-dev Reply:=C2=A0Pieter Wuille > Date:=C2=A0August 6, 2015 at 5:32:20 PM To:=C2=A0Dave Scotese > Cc:=C2=A0Bitcoin Dev > Subject:=C2=A0 Re: =5Bbitcoin-dev=5D Wrapping up the block size debate wi= th voting =20 On =46ri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev wrote: =22Miners can do this unilaterally=22 maybe, if they are a closed group, = based on the 51% rule. But aren't they using full nodes for propagation=3F= =C2=A0 In this sense, anyone can vote by coding. They don't need to use full nodes for propagation. Miners don't care when= other full nodes hear about their blocks, only whether they (eventually)= accept them. And yes, full nodes can change what blocks they accept. That's called a h= ard fork :) -- Pieter =C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 bitcoin-dev mailing list =20 bitcoin-dev=40lists.linuxfoundation.org =20 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =20 --55c3fdbc_4727356_180e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline