diff options
| author | Ryan Butler <rryananizer@gmail.com> | 2015-08-07 15:17:29 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-07 20:17:31 +0000 |
| commit | 7f924cdf9e2263a543f6d002149d01f05910ff15 (patch) | |
| tree | 8a22cff8cebe62c26ccb35d99a97ad40aa56f05c | |
| parent | 2ed4224322273dcedf7be3483d9e1c5390dd84b0 (diff) | |
| download | pi-bitcoindev-7f924cdf9e2263a543f6d002149d01f05910ff15.tar.gz pi-bitcoindev-7f924cdf9e2263a543f6d002149d01f05910ff15.zip | |
Re: [bitcoin-dev] Fees and the block-finding process
| -rw-r--r-- | 2b/b7b80ae7adbf49c397348e6d1d87712bca6b29 | 436 |
1 files changed, 436 insertions, 0 deletions
diff --git a/2b/b7b80ae7adbf49c397348e6d1d87712bca6b29 b/2b/b7b80ae7adbf49c397348e6d1d87712bca6b29 new file mode 100644 index 000000000..82395e7a8 --- /dev/null +++ b/2b/b7b80ae7adbf49c397348e6d1d87712bca6b29 @@ -0,0 +1,436 @@ +Return-Path: <rryananizer@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6121E8E6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 7 Aug 2015 20:17:31 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com + [209.85.218.53]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E1E0113B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 7 Aug 2015 20:17:29 +0000 (UTC) +Received: by oihn130 with SMTP id n130so62012050oih.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 07 Aug 2015 13:17:29 -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=BEt+R0m5dkOaza5QkFnUuWrq/w20TqEqLOPxCHJRv4w=; + b=Id3ZQu3ew/3bG9iDI1gjU14VGWyquVlYD0RpJ0R696MeWiSMrvGRIK7jOkrHu1g1Jt + EK85Xr3WZSNH0adjKKOy0ctpImMjBQCyA3H+rW+ztGQQcfPKlJt5waxtA8CCyj7zdCzW + u3LoFLvsBiloGay7ZR9KEzp9Lhy142LqZ+obF4vMVLwIars5rns94dm5K3nBLUutwUOL + 8LnaJluC/oDSAk6eWl08RhB7dKYc2RrWIx/KNPmyQqsqHlQgrHX/z3wqmLqDx3nUi9XC + BzrUcElW6EUoJYatNAr6c27OEBasmNSdAXmaTYYZ4yo/aBCjnG+lTrMrNVB5U/PkKl/X + lTEw== +MIME-Version: 1.0 +X-Received: by 10.202.51.66 with SMTP id z63mr8111709oiz.89.1438978649308; + Fri, 07 Aug 2015 13:17:29 -0700 (PDT) +Received: by 10.202.220.6 with HTTP; Fri, 7 Aug 2015 13:17:29 -0700 (PDT) +Received: by 10.202.220.6 with HTTP; Fri, 7 Aug 2015 13:17:29 -0700 (PDT) +In-Reply-To: <CAOG=w-s6x57Ab6=Q47abD4aYaUb18OUnoNqGaX4s3Awb7tNQoA@mail.gmail.com> +References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com> + <CAPg+sBgOt=qhQVZv5P-4mcD75=L4PKgOfRqhyB6FZdSYQajrwQ@mail.gmail.com> + <CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com> + <CAPg+sBiaT-2sjedA1mLOQo+q7=DjJ2yRuy7E4Gb3Wn8R-DzRTQ@mail.gmail.com> + <CAF_2MyUtrBUnR6EN-mOOnDa+Xh9=2coo9GaUcaeHCREqfP7jxA@mail.gmail.com> + <CAOG=w-uOxD0qntS4zWibV-khUYfKkjbsf84DbFR9WGV=FqQYxQ@mail.gmail.com> + <CAF_2MyVoL7_7jPZX-aftfcjV59nCP1q5bOK-Xyn8JoqyqysXLg@mail.gmail.com> + <CAF_2MyUqf3Qf7aj6DXy81AycD7EoyZTMsHKih1yfvAmy1BS+wA@mail.gmail.com> + <CAOG=w-s6x57Ab6=Q47abD4aYaUb18OUnoNqGaX4s3Awb7tNQoA@mail.gmail.com> +Date: Fri, 7 Aug 2015 15:17:29 -0500 +Message-ID: <CAF_2MyXumMsx2nzpoxkGZjXarj6tbAsm+37RwPs-nsi+zaUdGw@mail.gmail.com> +From: Ryan Butler <rryananizer@gmail.com> +To: Mark Friedenbach <mark@friedenbach.org> +Content-Type: multipart/alternative; boundary=001a113ce1b43b4327051cbe5356 +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 <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Fees and the block-finding process +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: Fri, 07 Aug 2015 20:17:31 -0000 + +--001a113ce1b43b4327051cbe5356 +Content-Type: text/plain; charset=UTF-8 + +Peter's proposal undercuts matching blocksize growth to technological +progress not limiting centralization pressure. They are somewhat related, +but I want to be clear on what I originally stated. I would also point out +that Peter's proposal lacks this technical criteria as well. + +That being said, I think designing any growth rates on theoretical +centralization pressure is not sensible and Peter's proposal rightly +excludes it and attempts instead for a very gradual increase over time +attempting to match blocksize growth that is consistent with technological +bandwidth growth. The problem is that it ignores the last 6 years (we are +already "behind") and underestimates bandwidth and storage growth. (See +Nielsen's law which states 50% and has held for 30 years). + +Peter seems to be of the belief that since bitcoin will never be able to +handle all the world's transactions we should instead "...decrease the need +for trust required in off-chain systems...". This is akin to basing all +the world's transactions on a small settlement layer, much like balancing a +pyramid upside down it will topple. + +I'm of the belief that the "reasonable node" test is a simple enough test +to maintain decentralization. + +A raspberry pie 2 node on reasonable Internet connection with a reasonable +hard drive can run a node with 8 or 20mb blocks easily. + +As Peter's proposal indicates, "If over time, this growth factor is beyond +what the actual technology offers, the intention should be to soft fork a +tighter limit." I wholeheartedly agree, which is why we should plan to be +ahead of the curve...not behind it. +On Aug 7, 2015 2:15 PM, "Mark Friedenbach" <mark@friedenbach.org> wrote: + +> Surely you have some sort of empirical measurement demonstrating the +> validity of that statement? That is to say you've established some +> technical criteria by which to determine how much centralization pressure +> is too much, and shown that Pieter's proposal undercuts expected progress +> in that area? +> +> On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler <rryananizer@gmail.com> +> wrote: +> +>> Clarification... +>> +>> These are not mutually exclusive. We can design an increase to blocksize +>> that increases available space on chain AND follow technological +>> evolution. Peter's latest proposal is way too conservative on that front. +>> +>> And given Peter's assertion that demand is infinite there will still be a +>> an ocean of off chain transactions for the likes of blockstream to address. +>> On Aug 7, 2015 1:57 PM, "Ryan Butler" <rryananizer@gmail.com> wrote: +>> +>>> Who said anything about scaling bitcoin to visa levels now? We're +>>> talking about an increase now that scales into the future at a rate that is +>>> consistent with technological progress. +>>> +>>> Peter himself said "So, I think the block size should follow +>>> technological evolution...". +>>> +>>> The blocksize increase proposals have been modeled around this very +>>> thing. It's reasonable to increase the blocksize to a point that a +>>> reasonable person, with reasonable equipment and internet access can run a +>>> node or even a miner with acceptable orphan rates. Most miners are spv +>>> mining anyways. The 8 or even 20 MB limits are within those parameters. +>>> +>>> These are not mutually exclusive. We can design an increase to +>>> blocksize that addresses both demand exceeding the available space AND +>>> follow technological evolution. Peter's latest proposal is way too +>>> conservative on that front. +>>> On Aug 7, 2015 1:25 PM, "Mark Friedenbach" <mark@friedenbach.org> wrote: +>>> +>>>> Please don't put words into Pieter's mouth. I guarantee you everyone +>>>> working on Bitcoin in their heart of hearts would prefer everyone in the +>>>> world being able to use the Bitcoin ledger for whatever purpose, if there +>>>> were no cost. +>>>> +>>>> But like any real world engineering issue, this is a matter of +>>>> tradeoffs. At the extreme it is simply impossible to scale Bitcoin to the +>>>> terrabyte sized blocks that would be necessary to service the entire +>>>> world's financial transactions. Not without sacrificing entirely the +>>>> protection of policy neutrality achieved through decentralization. And as +>>>> that is Bitcoin's only advantage over traditional consensus systems, you +>>>> would have to wonder what the point of such an endeavor would be. +>>>> +>>>> So *somewhere* you have to draw the line, and transactions below that +>>>> level are simply pushed into higher level or off-chain protocols. +>>>> +>>>> The issue, as Pieter and Jorge have been pointing out, is that +>>>> technical discussion over where that line should be has been missing from +>>>> this debate. +>>>> +>>>> On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev < +>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>>>> +>>>>> Interesting position there Peter...you fear more people actually using +>>>>> bitcoin. The less on chain transactions the lower the velocity and the +>>>>> lower the value of the network. I would be careful what you ask for +>>>>> because you end up having nothing left to even root the security of these +>>>>> off chain transactions with and then neither will exist. +>>>>> +>>>>> Nobody ever said you wouldn't run out of capacity at any size. It's +>>>>> quite the fallacy to draw the conclusion from that statement that block +>>>>> size should remain far below a capacity it can easily maintain which would +>>>>> bring more users/velocity/value to the system. The outcomes of both of +>>>>> those scenarios are asymmetric. A higher block size can support more users +>>>>> and volume. +>>>>> +>>>>> Raising the blocksize isn't out of fear. It's the realization that we +>>>>> are at a point where we can raise it and support more users and +>>>>> transactions while keeping the downsides to a minimum (centralization etc). +>>>>> On Aug 7, 2015 11:28 AM, "Pieter Wuille via bitcoin-dev" < +>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>>>>> +>>>>>> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen < +>>>>>> gavinandresen@gmail.com> wrote: +>>>>>> +>>>>>>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille < +>>>>>>> pieter.wuille@gmail.com> wrote: +>>>>>>> +>>>>>>>> I guess my question (and perhaps that's what Jorge is after): do +>>>>>>>> you feel that blocks should be increased in response to (or for fear of) +>>>>>>>> such a scenario. +>>>>>>>> +>>>>>>> +>>>>>>> I think there are multiple reasons to raise the maximum block size, +>>>>>>> and yes, fear of Bad Things Happening as we run up against the 1MB limit is +>>>>>>> one of the reasons. +>>>>>>> +>>>>>>> I take the opinion of smart engineers who actually do resource +>>>>>>> planning and have seen what happens when networks run out of capacity very +>>>>>>> seriously. +>>>>>>> +>>>>>> +>>>>>> This is a fundamental disagreement then. I believe that the demand is +>>>>>> infinite if you don't set a fee minimum (and I don't think we should), and +>>>>>> it just takes time for the market to find a way to fill whatever is +>>>>>> available - the rest goes into off-chain systems anyway. You will run out +>>>>>> of capacity at any size, and acting out of fear of that reality does not +>>>>>> improve the system. Whatever size blocks are actually produced, I believe +>>>>>> the result will either be something people consider too small to be +>>>>>> competitive ("you mean Bitcoin can only do 24 transactions per second?" +>>>>>> sounds almost the same as "you mean Bitcoin can only do 3 transactions per +>>>>>> second?"), or something that is very centralized in practice, and likely +>>>>>> both. +>>>>>> +>>>>>> +>>>>>>> And if so, if that is a reason for increase now, won't it be a +>>>>>>>> reason for an increase later as well? It is my impression that your answer +>>>>>>>> is yes, that this is why you want to increase the block size quickly and +>>>>>>>> significantly, but correct me if I'm wrong. +>>>>>>>> +>>>>>>> +>>>>>>> Sure, it might be a reason for an increase later. Here's my message +>>>>>>> to in-the-future Bitcoin engineers: you should consider raising the +>>>>>>> maximum block size if needed and you think the benefits of doing so (like +>>>>>>> increased adoption or lower transaction fees or increased reliability) +>>>>>>> outweigh the costs (like higher operating costs for full-nodes or the +>>>>>>> disruption caused by ANY consensus rule change). +>>>>>>> +>>>>>> +>>>>>> In general that sounds reasonable, but it's a dangerous precedent to +>>>>>> make technical decisions based on a fear of change of economics... +>>>>>> +>>>>>> -- +>>>>>> Pieter +>>>>>> +>>>>>> +>>>>>> _______________________________________________ +>>>>>> bitcoin-dev mailing list +>>>>>> bitcoin-dev@lists.linuxfoundation.org +>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>>>>> +>>>>>> +>>>>> _______________________________________________ +>>>>> bitcoin-dev mailing list +>>>>> bitcoin-dev@lists.linuxfoundation.org +>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>>>> +>>>>> +>>>> +> + +--001a113ce1b43b4327051cbe5356 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<p dir=3D"ltr">Peter's proposal undercuts matching blocksize growth to = +technological progress not limiting centralization pressure.=C2=A0 They are= + somewhat related, but I want to be clear on what I originally stated.=C2= +=A0 I would also point out that Peter's proposal lacks this technical c= +riteria as well.</p> +<p dir=3D"ltr">That being said, I think designing any growth rates on theor= +etical centralization pressure is not sensible and Peter's proposal rig= +htly excludes it and attempts instead for a very gradual increase over time= + attempting to match blocksize growth that is consistent with technological= + bandwidth growth.=C2=A0 The problem is that it ignores the last 6 years (w= +e are already "behind") and underestimates bandwidth and storage = +growth. (See Nielsen's law which states 50% and has held for 30 years).= +</p> +<p dir=3D"ltr">Peter seems to be of the belief that since bitcoin will neve= +r be able to handle all the world's transactions we should instead &quo= +t;...decrease the need for trust required in off-chain systems...".=C2= +=A0 This is akin to basing all the world's transactions on a small sett= +lement layer, much like balancing a pyramid upside down it will topple. </p= +> +<p dir=3D"ltr">I'm of the belief that the "reasonable node" t= +est is a simple enough test to maintain decentralization.</p> +<p dir=3D"ltr">A raspberry pie 2 node on reasonable Internet connection wit= +h a reasonable hard drive can run a node with 8 or 20mb blocks easily.</p> +<p dir=3D"ltr">As Peter's proposal indicates, "If over time, this = +growth factor is beyond what the actual technology offers, the intention sh= +ould be to soft fork a tighter limit."=C2=A0 I wholeheartedly agree, w= +hich is why we should plan to be ahead of the curve...not behind it.</p> +<div class=3D"gmail_quote">On Aug 7, 2015 2:15 PM, "Mark Friedenbach&q= +uot; <<a href=3D"mailto:mark@friedenbach.org">mark@friedenbach.org</a>&g= +t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style= +=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir= +=3D"ltr">Surely you have some sort of empirical measurement demonstrating t= +he validity of that statement? That is to say you've established some t= +echnical criteria by which to determine how much centralization pressure is= + too much, and shown that Pieter's proposal undercuts expected progress= + in that area?<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_= +quote">On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler <span dir=3D"ltr"><<= +a href=3D"mailto:rryananizer@gmail.com" target=3D"_blank">rryananizer@gmail= +.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"= +>Clarification...</p> +<p dir=3D"ltr">These are not mutually exclusive.=C2=A0 We can design an inc= +rease to blocksize that increases available space on chain AND follow techn= +ological evolution.=C2=A0 Peter's latest proposal is way too conservati= +ve on that front.</p> +<p dir=3D"ltr">And given Peter's assertion that demand is infinite ther= +e will still be a an ocean of off chain transactions for the likes of block= +stream to address.<br> +</p><div><div> +<div class=3D"gmail_quote">On Aug 7, 2015 1:57 PM, "Ryan Butler" = +<<a href=3D"mailto:rryananizer@gmail.com" target=3D"_blank">rryananizer@= +gmail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail= +_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= +1ex"><p dir=3D"ltr">Who said anything about scaling bitcoin to visa levels = +now?=C2=A0 We're talking about an increase now that scales into the fut= +ure at a rate that is consistent with technological progress.</p> +<p dir=3D"ltr">Peter himself said "So, I think the block size should f= +ollow technological evolution...".</p> +<p dir=3D"ltr">The blocksize increase proposals have been modeled around th= +is very thing.=C2=A0 It's reasonable to increase the blocksize to a poi= +nt that a reasonable person, with reasonable equipment and internet access = +can run a node or even a miner with acceptable orphan rates.=C2=A0 Most min= +ers are spv mining anyways.=C2=A0 The 8 or even 20 MB limits are within tho= +se parameters.</p> +<p dir=3D"ltr">These are not mutually exclusive.=C2=A0 We can design an inc= +rease to blocksize that addresses both demand exceeding the available space= + AND follow technological evolution.=C2=A0 Peter's latest proposal is w= +ay too conservative on that front.</p> +<div class=3D"gmail_quote">On Aug 7, 2015 1:25 PM, "Mark Friedenbach&q= +uot; <<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@fri= +edenbach.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gm= +ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= +ft:1ex"><div dir=3D"ltr"><div><div><div>Please don't put words into Pie= +ter's mouth. I guarantee you everyone working on Bitcoin in their heart= + of hearts would prefer everyone in the world being able to use the Bitcoin= + ledger for whatever purpose, if there were no cost.<br><br></div>But like = +any real world engineering issue, this is a matter of tradeoffs. At the ext= +reme it is simply impossible to scale Bitcoin to the terrabyte sized blocks= + that would be necessary to service the entire world's financial transa= +ctions. Not without sacrificing entirely the protection of policy neutralit= +y achieved through decentralization. And as that is Bitcoin's only adva= +ntage over traditional consensus systems, you would have to wonder what the= + point of such an endeavor would be.<br><br></div>So *somewhere* you have t= +o draw the line, and transactions below that level are simply pushed into h= +igher level or off-chain protocols.<br><br></div>The issue, as Pieter and J= +orge have been pointing out, is that technical discussion over where that l= +ine should be has been missing from this debate.<br></div><div class=3D"gma= +il_extra"><br><div class=3D"gmail_quote">On Fri, Aug 7, 2015 at 10:47 AM, R= +yan Butler via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-= +dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou= +ndation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir= +=3D"ltr">Interesting position there Peter...you fear more people actually u= +sing bitcoin.=C2=A0 The less on chain transactions the lower the velocity a= +nd the lower the value of the network.=C2=A0 I would be careful what you as= +k for because you end up having nothing left to even root the security of t= +hese off chain transactions with and then neither will exist.</p> +<p dir=3D"ltr">Nobody ever said you wouldn't run out of capacity at any= + size.=C2=A0 It's quite the fallacy to draw the conclusion from that st= +atement that block size should remain far below a capacity it can easily ma= +intain which would bring more users/velocity/value to the system.=C2=A0 The= + outcomes of both of those scenarios are asymmetric.=C2=A0 A higher block s= +ize can support more users and volume.</p> +<p dir=3D"ltr">Raising the blocksize isn't out of fear.=C2=A0 It's = +the realization that we are at a point where we can raise it and support mo= +re users and transactions while keeping the downsides to a minimum (central= +ization etc).</p> +<div class=3D"gmail_quote"><div><div>On Aug 7, 2015 11:28 AM, "Pieter = +Wuille via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxf= +oundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&= +gt; wrote:<br type=3D"attribution"></div></div><blockquote class=3D"gmail_q= +uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= +x"><div><div><div dir=3D"ltr">On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andrese= +n <span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target= +=3D"_blank">gavinandresen@gmail.com</a>></span> wrote:<br><div class=3D"= +gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s= +tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div= + dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span>On= + Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <span dir=3D"ltr"><<a href= +=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.c= +om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= +in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"= +><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I guess my ques= +tion (and perhaps that's what Jorge is after): do you feel that blocks = +should be increased in response to (or for fear of) such a scenario. </div>= +</div></div></div></blockquote><div><br></div></span><div>I think there are= + multiple reasons to raise the maximum block size, and yes, fear of Bad Thi= +ngs Happening as we run up against the 1MB limit is one of the reasons.</di= +v><div><br></div><div>I take the opinion of smart engineers who actually do= + resource planning and have seen what happens when networks run out of capa= +city very seriously.</div></div></div></div></blockquote><div><br></div><di= +v>This is a fundamental disagreement then. I believe that the demand is inf= +inite if you don't set a fee minimum (and I don't think we should),= + and it just takes time for the market to find a way to fill whatever is av= +ailable - the rest goes into off-chain systems anyway. You will run out of = +capacity at any size, and acting out of fear of that reality does not impro= +ve the system. Whatever size blocks are actually produced, I believe the re= +sult will either be something people consider too small to be competitive (= +"you mean Bitcoin can only do 24 transactions per second?" sounds= + almost the same as "you mean Bitcoin can only do 3 transactions per s= +econd?"), or something that is very centralized in practice, and likel= +y both.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = +0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c= +lass=3D"gmail_extra"><div class=3D"gmail_quote"><span><div><br></div><block= +quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= + solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c= +lass=3D"gmail_quote"><div>And if so, if that is a reason for increase now, = +won't it be a reason for an increase later as well? It is my impression= + that your answer is yes, that this is why you want to increase the block s= +ize quickly and significantly, but correct me if I'm wrong. <br></div><= +/div></div></div></blockquote><div><br></div></span><div>Sure, it might be = +a reason for an increase later. Here's my message to in-the-future Bitc= +oin engineers: =C2=A0you should consider raising the maximum block size if = +needed and you think the benefits of doing so (like increased adoption or l= +ower transaction fees or increased reliability) outweigh the costs (like hi= +gher operating costs for full-nodes or the disruption caused by ANY consens= +us rule change).</div></div></div></div></blockquote><br></div><div class= +=3D"gmail_quote">In general that sounds reasonable, but it's a dangerou= +s precedent to make technical decisions based on a fear of change of econom= +ics...<br><br>-- <br></div><div class=3D"gmail_quote">Pieter<br><br></div><= +/div></div> +<br></div></div>_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +<br></blockquote></div> +<br>_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +<br></blockquote></div><br></div> +</blockquote></div> +</blockquote></div> +</div></div></blockquote></div><br></div> +</blockquote></div> + +--001a113ce1b43b4327051cbe5356-- + |