diff options
| author | Bryan Bishop <kanzure@gmail.com> | 2015-12-26 18:13:40 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-12-27 00:13:42 +0000 |
| commit | 6415c39c1450e494a4f3da4e90d4ff3301224c23 (patch) | |
| tree | 6515f55da797dfdafd3574606a4fb776dc9fabbf | |
| parent | 217a1b1f5c1abd307689d8bb60c2d9702527c5b3 (diff) | |
| download | pi-bitcoindev-6415c39c1450e494a4f3da4e90d4ff3301224c23.tar.gz pi-bitcoindev-6415c39c1450e494a4f3da4e90d4ff3301224c23.zip | |
Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
| -rw-r--r-- | 70/bb878c8012917873fdae7e912005541a48d591 | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/70/bb878c8012917873fdae7e912005541a48d591 b/70/bb878c8012917873fdae7e912005541a48d591 new file mode 100644 index 000000000..57b959414 --- /dev/null +++ b/70/bb878c8012917873fdae7e912005541a48d591 @@ -0,0 +1,193 @@ +Return-Path: <kanzure@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B8D011E7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Dec 2015 00:13:42 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io0-f175.google.com (mail-io0-f175.google.com + [209.85.223.175]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 838F0CC + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 27 Dec 2015 00:13:41 +0000 (UTC) +Received: by mail-io0-f175.google.com with SMTP id 186so284270262iow.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 26 Dec 2015 16:13:41 -0800 (PST) +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=i5PSYZ+aqxlBwq3+oslFgmPQar2j/8b4wjCk3KYeKJk=; + b=T1kN73tsUHY47Id5awR0RTIF9rzwjCTtJD2y/7zMm7qwDLhHi84J4vyeeHCJIC+Fu7 + P9wOT0YoR9ClfViaUxBUJMXKc8X2Gp9fvFqOvhWFL2lGMU4b+nJrIVl18jHO1C99VRvE + DOAvT3tW9KhBtivU8jng2dWgSxFdP+eCqGkcKTAu2OmG4HLvzOZttmzpSvcbxZ3/rK1N + qexU9805keHuxMwBO8eUwU8Dv7YSuCzR2tUAQi1DgyTboE7p+3H7y/xRjSz9E2LJlGAb + yItuT6j/Rd3SV6OuYMXIHGOFGahXlhkj0eaQlY714FtqXrxNAtgqEnJe6/zUKkK9doN4 + +/7g== +MIME-Version: 1.0 +X-Received: by 10.107.62.136 with SMTP id l130mr32543934ioa.28.1451175221072; + Sat, 26 Dec 2015 16:13:41 -0800 (PST) +Received: by 10.36.66.132 with HTTP; Sat, 26 Dec 2015 16:13:40 -0800 (PST) +In-Reply-To: <567F1F7A.6070700@openbitcoinprivacyproject.org> +References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com> + <CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com> + <CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com> + <CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com> + <CA+c4Zozac8=aMrAJ1N_6SR9eBD+w0e70cEnk9CG_2oZ72AS-8g@mail.gmail.com> + <CAPg+sBhsKD8jd9Y9+ngXY5tKUheO3d4P1b47eYL=Uzpat+KJ2w@mail.gmail.com> + <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com> + <CAPg+sBiT5=ss9e=iac6J-A=85okF0zxMeV7H4z9-Qfx3CAWHXA@mail.gmail.com> + <246AA3BE-570D-4B88-A63D-AC76CB2B0CB8@toom.im> + <CAPg+sBhxnxnQQ-SpWuJ-+_uxRwXkgcU07jkYdZ8BcBwVDyW-vg@mail.gmail.com> + <567F1F7A.6070700@openbitcoinprivacyproject.org> +Date: Sat, 26 Dec 2015 18:13:40 -0600 +Message-ID: <CABaSBazeNk5_GaWiQerYxgB0VJko9AX+Yq1LaUJVpZTSinGt9A@mail.gmail.com> +From: Bryan Bishop <kanzure@gmail.com> +To: Justus Ranvier <justus@openbitcoinprivacyproject.org>, + Bryan Bishop <kanzure@gmail.com> +Content-Type: multipart/alternative; boundary=94eb2c0883e08f1a400527d60fe0 +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] Block size: It's economics & user preparation & + moral hazard +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, 27 Dec 2015 00:13:42 -0000 + +--94eb2c0883e08f1a400527d60fe0 +Content-Type: text/plain; charset=UTF-8 + +On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote: +> > I think the shortest reasonable timeframe for an uncontroversial +> > hardfork is somewhere in the range between 6 and 12 months. +> +> This argument would hold more weight if it didn't looks like a stalling +> tactic in context. +> + +I think you'll find that there hasn't been stalling regarding an +uncontroversial hard-fork deployment. You might be confusing an +uncontroversial hard-fork decision instead with how developers have brought +up many issues about various (hard-forking) block size proposals.... I +suspect this is what you're intending to mention instead, given your +mention of "capacity emergencies" and also the subject line. + + +> 6 months ago, there was a concerted effort to being the process then, +> for exactly this reason. +> + +The uncontroversial hard-fork proposals from 6 months ago were mostly along +the lines of jtimon's proposals, which were not about capacity. (Although, +I should say "almost entirely uncontroversial"-- obviously has been some +minor (and in my opinion, entirely solvable) disagreement regarding +prioritization of deploying a jtimon's uncontroversial hard-fork idea I +guess, seeing as how it has not yet happened.) + + +> After 6 months of denial, stonewalling, and generally unproductive +> fighting, the need for proactivity is being acknowledged with no +> reference to the delay. +> + +There wasn't 6 months of "stonewalling" or "denial" about an +uncontroversial hard-fork proposal. There has been extensive discussion +regarding the controversial (flawed?) properties of other (block size) +proposals. But that's something else. Much of this has been rehashed ad +nauseum on this mailing list already... thankfully I think your future +emails could be improved and made more useful if you were to read the +mailing list archives, try to employ more careful reasoning, etc. Thanks. + + +> If the network ever ends up making a hasty forced upgrade to solve a +> capacity emergency the responsibility for that difficulty will not fall +> on those who did their best to prevent emergency upgrades by planning +> ahead. +> + +("Capacity emergency" is too ambiguous in this context because of the +competing concerns and tradeoffs regarding transaction rate capacity +exhaustion vs. p2p low-bandwidth node bandwidth exhaustion.) + +- Bryan +http://heybryan.org/ +1 512 203 0507 + +--94eb2c0883e08f1a400527d60fe0 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S= +at, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev <span dir=3D"lt= +r"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_= +blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><bloc= +kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-= +width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin= +g-left:1ex"><span class=3D"">On 12/26/2015 05:01 PM, Pieter Wuille via bitc= +oin-dev wrote:<br> +> I think the shortest reasonable timeframe for an uncontroversial<br> +> hardfork is somewhere in the range between 6 and 12 months.<br> +<br> +</span>This argument would hold more weight if it didn't looks like a s= +talling<br> +tactic in context.<br></blockquote><div><br></div><div>I think you'll f= +ind that there hasn't been stalling regarding an uncontroversial hard-f= +ork deployment. You might be confusing an uncontroversial hard-fork decisio= +n instead with how developers have brought up many issues about various (ha= +rd-forking) block size proposals.... I suspect this is what you're inte= +nding to mention instead, given your mention of "capacity emergencies&= +quot; and also the subject line.</div><div>=C2=A0<br></div><blockquote clas= +s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b= +order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"= +>6 months ago, there was a concerted effort to being the process then,<br> +for exactly this reason.<br></blockquote><div><br></div><div>The uncontrove= +rsial hard-fork proposals from 6 months ago were mostly along the lines of = +jtimon's proposals, which were not about capacity. (Although, I should = +say "almost entirely uncontroversial"-- obviously has been some m= +inor (and in my opinion, entirely solvable) disagreement regarding prioriti= +zation of deploying a jtimon's uncontroversial hard-fork idea I guess, = +seeing as how it has not yet happened.)</div><div>=C2=A0</div><blockquote c= +lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p= +x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1= +ex"> +After 6 months of denial, stonewalling, and generally unproductive<br> +fighting, the need for proactivity is being acknowledged with no<br> +reference to the delay.<br></blockquote><div><br></div><div>There wasn'= +t 6 months of "stonewalling" or "denial" about an uncon= +troversial hard-fork proposal. There has been extensive discussion regardin= +g the controversial (flawed?) properties of other (block size) proposals. B= +ut that's something else. Much of this has been rehashed ad nauseum=C2= +=A0on this mailing list already... =C2=A0thankfully I think your future ema= +ils could be improved and made more useful if you were to read the mailing = +list archives, try to employ more careful reasoning, etc. Thanks.</div><div= +>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = +0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-= +style:solid;padding-left:1ex">If the network ever ends up making a hasty fo= +rced upgrade to solve a<br> +capacity emergency the responsibility for that difficulty will not fall<br> +on those who did their best to prevent emergency upgrades by planning ahead= +.<br></blockquote></div><br>("Capacity emergency" is too ambiguou= +s in this context because of the competing concerns and tradeoffs regarding= + transaction rate capacity exhaustion vs. p2p low-bandwidth node bandwidth = +exhaustion.)<br><div><br></div><div class=3D"gmail_signature">- Bryan<br><a= + href=3D"http://heybryan.org/" target=3D"_blank">http://heybryan.org/</a><b= +r>1 512 203 0507</div> +</div></div> + +--94eb2c0883e08f1a400527d60fe0-- + |