diff options
| author | Michael Naber <mickeybob@gmail.com> | 2015-08-06 13:43:43 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-06 18:43:46 +0000 |
| commit | 1c45f1e70bf0550ffafc277c058e6aacdbfad14e (patch) | |
| tree | 28e43082d71e6a56a0b292257351bc17ef89499c | |
| parent | e9ec8b716ff39716448593c5e002d9e1f81cc6e5 (diff) | |
| download | pi-bitcoindev-1c45f1e70bf0550ffafc277c058e6aacdbfad14e.tar.gz pi-bitcoindev-1c45f1e70bf0550ffafc277c058e6aacdbfad14e.zip | |
Re: [bitcoin-dev] Fwd: Block size following technological growth
| -rw-r--r-- | 1a/ed219b93e752cc57a1e7e8c30dcfa958caa1da | 266 |
1 files changed, 266 insertions, 0 deletions
diff --git a/1a/ed219b93e752cc57a1e7e8c30dcfa958caa1da b/1a/ed219b93e752cc57a1e7e8c30dcfa958caa1da new file mode 100644 index 000000000..1bfd9fb63 --- /dev/null +++ b/1a/ed219b93e752cc57a1e7e8c30dcfa958caa1da @@ -0,0 +1,266 @@ +Return-Path: <mickeybob@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C7648BA + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 18:43:46 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com + [209.85.212.181]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33DD915D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Aug 2015 18:43:45 +0000 (UTC) +Received: by wicgj17 with SMTP id gj17so33812163wic.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 06 Aug 2015 11:43:44 -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=p6ghhFVsal2wL+0pv2H5yaq/BIYEqHATh2TGB7XGveM=; + b=lbJLpIwri2v0jX/BgNq0GjaHKYGDtTb/loAsI19ZhHTL/t/4HrNf0fGK+pcYNdsMTi + 6qnEVY0BHwIjFj1AeiR5EVaENimOfUtIKZv8J6+9ljECqpeWDqLvkbYCtpsvQVeQ3qEP + HSJYcQMpw5JngNbLWhtkYFvSdARuBiSsTbcokT7I3IXWRI0IhQwmDCAQBDgrq0UfbPjT + oD+UbQO3HJIZ1WOGZFpx1XzoGM/+hoKMA9UMzRh0bXvtzfK+e8YM7Ob6y+onnQlwtU6n + 9t6mRBhEWNommgtYQTXp65FBfSlTbcDbbFLwB9zIU6q+BSGv9UfVoXp4AitRG34PBm/c + 1YSg== +MIME-Version: 1.0 +X-Received: by 10.180.20.71 with SMTP id l7mr9245403wie.32.1438886623969; Thu, + 06 Aug 2015 11:43:43 -0700 (PDT) +Received: by 10.27.78.207 with HTTP; Thu, 6 Aug 2015 11:43:43 -0700 (PDT) +In-Reply-To: <CAPg+sBhn-Gw7x6RNCo39b_GoS+BmSa0bckjaJGz-uK1QEwp4zQ@mail.gmail.com> +References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com> + <CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com> + <CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com> + <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com> + <CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com> + <CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com> + <CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com> + <CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com> + <CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com> + <CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com> + <CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com> + <CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_w@mail.gmail.com> + <CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com> + <CABsx9T22KUcbRb4ZfRDikbxK05pqWY1=uvYo10toWA-JwGa-PQ@mail.gmail.com> + <CAPg+sBg-KN5=A5_Fx3fo0dcD6mAdMUXBMNzW52SkQsRbADTmSg@mail.gmail.com> + <CABsx9T0QP3bmUkOSaD9X7zhcV3BNwT3xFZcsZnk+JL5oz-EfsA@mail.gmail.com> + <CAPg+sBi-Ls3Kuk=KE5EApqCh8amkGTUEs9a-jh--vVXs4PtxCQ@mail.gmail.com> + <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com> + <CABsx9T1tujBCwydDC_q6d=qV1DiA0PE=fMHCpAJVjv84rx_RSw@mail.gmail.com> + <CAPg+sBhn-Gw7x6RNCo39b_GoS+BmSa0bckjaJGz-uK1QEwp4zQ@mail.gmail.com> +Date: Thu, 6 Aug 2015 13:43:43 -0500 +Message-ID: <CALgxB7vqA=o1L0aftMtzNYC_OYJcVw6vuqUeB3a2F6d+VuoJkA@mail.gmail.com> +From: Michael Naber <mickeybob@gmail.com> +To: Pieter Wuille <pieter.wuille@gmail.com> +Content-Type: multipart/alternative; boundary=bcaec53f2e271808d5051ca8e6fb +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] 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 <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: Thu, 06 Aug 2015 18:43:46 -0000 + +--bcaec53f2e271808d5051ca8e6fb +Content-Type: text/plain; charset=UTF-8 + +How many nodes are necessary to ensure sufficient network reliability? Ten, +a hundred, a thousand? At what point do we hit the point of diminishing +returns, where adding extra nodes starts to have negligible impact on the +overall reliability of the system? + + + + + +On Thu, Aug 6, 2015 at 10:26 AM, Pieter Wuille via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen <gavinandresen@gmail.com> +> wrote: +> +>> On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille <pieter.wuille@gmail.com> +>> wrote: +>> +>>> So if we would have 8 MB blocks, and there is a sudden influx of users +>>> (or settlement systems, who serve much more users) who want to pay high +>>> fees (let's say 20 transactions per second) making the block chain +>>> inaccessible for low fee transactions, and unreliable for medium fee +>>> transactions (for any value of low, medium, and high), would you be ok with +>>> that? +>> +>> +>> Yes, that's fine. If the network cannot handle the transaction volume +>> that people want to pay for, then the marginal transactions are priced out. +>> That is true today (otherwise ChangeTip would be operating on-blockchain), +>> and will be true forever. +>> +> +> The network can "handle" any size. I believe that if a majority of miners +> forms SPV mining agreements, then they are no longer affected by the block +> size, and benefit from making their blocks slow to validate for others (as +> long as the fee is negligable compared to the subsidy). I'll try to find +> the time to implement that in my simulator. Some hardware for full nodes +> will always be able to validate and index the chain, so nobody needs to run +> a pesky full node anymore and they can just use a web API to validate +> payments. +> +> Being able the "handle" a particular rate is not a boolean question. It's +> a question of how much security, centralization, and risk for systemic +> error we're willing to tolerate. These are not things you can just observe, +> so let's keep talking about the risks, and find a solution that we agree on. +> +> +>> +>>> If so, why is 8 MB good but 1 MB not? To me, they're a small constant +>>> factor that does not fundamentally improve the scale of the system. +>> +>> +>> "better is better" -- I applaud efforts to fundamentally improve the +>> scalability of the system, but I am an old, cranky, pragmatic engineer who +>> has seen that successful companies tackle problems that arise and are +>> willing to deploy not-so-perfect solutions if they help whatever short-term +>> problem they're facing. +>> +> +> I don't believe there is a short-term problem. If there is one now, there +> will be one too at 8 MB blocks (or whatever actual size blocks are +> produced). +> +> +>> +>> +>>> I dislike the outlook of "being forever locked at the same scale" while +>>> technology evolves, so my proposal tries to address that part. It +>>> intentionally does not try to improve a small factor, because I don't think +>>> it is valuable. +>> +>> +>> I think consensus is against you on that point. +>> +> +> Maybe. But I believe that it is essential to not take unnecessary risks, +> and find a non-controversial solution. +> +> -- +> Pieter +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--bcaec53f2e271808d5051ca8e6fb +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">How many nodes are necessary to ensure sufficient network = +reliability? Ten, a hundred, a thousand? At what point do we hit the point = +of diminishing returns, where adding extra nodes starts to have negligible = +impact on the overall reliability of the system?=C2=A0<div><br></div><div><= +br><div><br></div><div><br></div></div></div><div class=3D"gmail_extra"><br= +><div class=3D"gmail_quote">On Thu, Aug 6, 2015 at 10:26 AM, Pieter Wuille = +via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.l= +inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org= +</a>></span> wrote:<br><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><span class=3D""><span>On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen <= +span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_= +blank">gavinandresen@gmail.com</a>></span> wrote:<br></span><span><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"><span>On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille <= +span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_= +blank">pieter.wuille@gmail.com</a>></span> wrote:<br><blockquote class= +=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= +ing-left:1ex">So + if we would have 8 MB blocks, and there is a sudden influx of users (or + settlement systems, who serve much more users) who want to pay high=20 +fees (let's say 20 transactions per second) making the block chain=20 +inaccessible for low fee transactions, and unreliable for medium fee=20 +transactions (for any value of low, medium, and high), would you be ok=20 +with that?</blockquote><div><br></div></span><div>Yes, that's fine. If= +=20 +the network cannot handle the transaction volume that people want to pay + for, then the marginal transactions are priced out. That is true today=20 +(otherwise ChangeTip would be operating on-blockchain), and will be true + forever.</div></div></div></div></blockquote><div><br></div></span></span>= +<div>The + network can "handle" any size. I believe that if a majority of m= +iners=20 +forms SPV mining agreements, then they are no longer affected by the=20 +block size, and benefit from making their blocks slow to validate for=20 +others (as long as the fee is negligable compared to the subsidy). I'll= +=20 +try to find the time to implement that in my simulator. Some hardware=20 +for full nodes will always be able to validate and index the chain, so=20 +nobody needs to run a pesky full node anymore and they can just use a=20 +web API to validate payments.<br><br></div><div>Being able the "handle= +" a + particular rate is not a boolean question. It's a question of how much= +=20 +security, centralization, and risk for systemic error we're willing to= +=20 +tolerate. These are not things you can just observe, so let's keep=20 +talking about the risks, and find a solution that we agree on.<br><br></div= +><span class=3D""><span><blockquote class=3D"gmail_quote" style=3D"margin:0= + 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di= +v class=3D"gmail_extra"><div class=3D"gmail_quote"><span><div>=C2=A0</div><= +blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= + #ccc solid;padding-left:1ex"> + If so, why is 8 MB good but 1 MB not? To me, they're a small constant= +=20 +factor that does not fundamentally improve the scale of the system.</blockq= +uote><div><br></div></span><div>"better + is better" -- I applaud efforts to fundamentally improve the=20 +scalability of the system, but I am an old, cranky, pragmatic engineer=20 +who has seen that successful companies tackle problems that arise and=20 +are willing to deploy not-so-perfect solutions if they help whatever=20 +short-term problem they're facing.</div></div></div></div></blockquote>= +<div><br></div></span></span><div>I + don't believe there is a short-term problem. If there is one now, ther= +e + will be one too at 8 MB blocks (or whatever actual size blocks are=20 +produced).<br>=C2=A0<br></div><span class=3D""><span><blockquote class=3D"g= +mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= +eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu= +ote"><span><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg= +in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + I dislike the outlook of "being forever locked at the same scale"= +; while + technology evolves, so my proposal tries to address that part. It=20 +intentionally does not try to improve a small factor, because I don't= +=20 +think it is valuable.</blockquote></span></div><br>I think consensus is aga= +inst you on that point.</div></div></blockquote><div><br></div></span></spa= +n><div>Maybe. But I believe that it is essential to not take unnecessary ri= +sks, and find a non-controversial solution.<span class=3D"HOEnZb"><font col= +or=3D"#888888"><br><br></font></span></div><span class=3D"HOEnZb"><font col= +or=3D"#888888">-- <br></font></span></div><span class=3D"HOEnZb"><font colo= +r=3D"#888888">Pieter<br><br></font></span></div> +<br>_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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> + +--bcaec53f2e271808d5051ca8e6fb-- + |