diff options
author | Jared Lee Richardson <jaredr26@gmail.com> | 2017-03-29 12:46:50 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-03-29 19:46:53 +0000 |
commit | dd9dc88fa42e19aca275be2b93756c4fb4a2de3b (patch) | |
tree | 729e4ad958e9a78b416631352039b65ba33dc28f | |
parent | 3555b6df082b4a59c45269385aa60224bfe2bb6c (diff) | |
download | pi-bitcoindev-dd9dc88fa42e19aca275be2b93756c4fb4a2de3b.tar.gz pi-bitcoindev-dd9dc88fa42e19aca275be2b93756c4fb4a2de3b.zip |
Re: [bitcoin-dev] Hard fork proposal from last week's meeting
-rw-r--r-- | 6d/c1a4537653219473ec4763e5ac0f46ee74c531 | 334 |
1 files changed, 334 insertions, 0 deletions
diff --git a/6d/c1a4537653219473ec4763e5ac0f46ee74c531 b/6d/c1a4537653219473ec4763e5ac0f46ee74c531 new file mode 100644 index 000000000..0004528f7 --- /dev/null +++ b/6d/c1a4537653219473ec4763e5ac0f46ee74c531 @@ -0,0 +1,334 @@ +Return-Path: <jaredr26@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A519BDE + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 19:46:53 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com + [209.85.213.54]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7E1D416C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 19:46:52 +0000 (UTC) +Received: by mail-vk0-f54.google.com with SMTP id r69so30611497vke.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 12:46:52 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to; + bh=ej+w9btLYGtiobURcGoBjWCAFyiwQmsKLysoXeXTgQM=; + b=I0FQepj6eLCN6zYGAHNlWpWh6eohztAaHOdW6OqL6c65ceMsV8xc/4py0cCEWafjhZ + pFAhisS0/NkEzdfbOsk86lMdRWmsGGfIc4c/Aiq6sm2Qmb7FfGf4u0j88XZobsk8bbI6 + YvlLxC9BdqhK6/KW67WIla7MV6I7bzYXdASgHgUn/D99jY9kxGmBLcDjvGkJiI3U8+3s + lV63ivojDBH0hruFIfHBC7M2s410Pa7CVWbUpNQR73C9lGBLQbwLS3ztIa5bCIsxqFRy + LlNfnTvLz2yZi+ZC+wq8OjjW/K2DYfPdVNU+B6fiqq9VhSf13Zq0no3UcGahJxVRWoX3 + xbyg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to; + bh=ej+w9btLYGtiobURcGoBjWCAFyiwQmsKLysoXeXTgQM=; + b=GzpgN4VtpM2S4zslSXPEzGKsxrYuW3R2klJG3+UoVKqcDcmpvN9BUzZa33H0GQNF9D + RzJTzlWTfgO4KXO6stwnpytXLoSgL5afKG9x38UpGflarKNBfZZNoHn0v7Yn5HA8+pb5 + j/za7JLly/jw/YQNqBIqz8WxUsI9eNv6aua/HgVvGDCPAsETZhbRjP8oBqhlpJ4zkOfL + Ws//St/XR/ruRsmvOAOtZWtYGqGsJGeQxJnK28hPE8Y9a/tH6Y03Bb+faLfDTrb1+Lwe + kJgqa7QpBJ2E+LVFbUzvsikOrGYlQ20EZiGw46uRWB9XLBIN3EQD9PU/7ApZLrCmTdZD + BGLg== +X-Gm-Message-State: AFeK/H1Tp2lA6KPk3vcbcw/5dD4wArokH54avftBfUsmNC45dEam4/kRKr8Jfeu+1FndE1mLijsGQ+4RvUyt0g== +X-Received: by 10.31.84.66 with SMTP id i63mr1063083vkb.157.1490816811435; + Wed, 29 Mar 2017 12:46:51 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 12:46:50 -0700 (PDT) +In-Reply-To: <CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com> +References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com> + <CAB-xxiPV9oN1r2hV5a=U1pcYuiZ_qmth-AM-H+1Cjgc2uw-0xA@mail.gmail.com> + <CAFVRnyr=cYf34X80+dLHwYEPHdqA7mMtYZ_gD6j09C+aM31gQQ@mail.gmail.com> +From: Jared Lee Richardson <jaredr26@gmail.com> +Date: Wed, 29 Mar 2017 12:46:50 -0700 +Message-ID: <CAD1TkXtnSApYgp9FU55Esn2qgT=QyqS61kVzSO1Ae=g8J18Vcw@mail.gmail.com> +To: David Vorick <david.vorick@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a114e523e788fd3054be3d6db +X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, + HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Wed, 29 Mar 2017 19:58:59 +0000 +Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol 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: Wed, 29 Mar 2017 19:46:53 -0000 + +--001a114e523e788fd3054be3d6db +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +> When considering what block size is acceptable, the impact of running +bitcoin in the background on affordable, non-dedicated home-hardware should +be a top consideration. + +Why is that a given? Is there math that outlines what the risk levels are +for various configurations of node distributions, vulnerabilities, etc? +How does one even evaluate the costs versus the benefits of node costs +versus transaction fees? + +> Disk space I believe is the most significant problem today, with RAM +being the second most significant problem, and finally bandwidth +consumption as the third most important consideration. I believe that v0.14 +is already too expensive on all three fronts, and that block size increases +shouldn't be considered at all until the requirements are reduced (or until +consumer hardware is better, but I believe we are talking 3-7 years of +waiting if we pick that option). + +Disk space is not the largest cost, either today or in the future. Without +historical checkpointing in some fashion, bandwidth costs are more than 2 +orders of magnitude higher cost than every other cost for full listening +nodes. With historical syncing discounted(i.e. pruned or nonlistening +nodes) bandwidth costs are still higher than hard drive costs. + + +Today: Full listening node, 133 peers, measured 1.5 TB/mo of bandwidth +consumption over two multi-day intervals. 1,500 GB/month @ ec2 low-tier +prices =3D $135/month, 110 GB storage =3D $4.95. Similar arguments extend = +to +consumer hardware - Comcast broadband is ~$80/mo depending on region and +comes with 1.0 TB cap in most regions, so $120/mo or even $80/mo would be +in the same ballpark. A consumer-grade 2GB hard drive is $70 and will last +for at least 2 years, so $2.93/month if the hard drive was totally +dedicated to Bitcoin and $0.16/month if we only count the percentage that +Bitcoin uses. + +For a non-full listening node, ~25 peers I measured around 70 GB/month of +usage over several days, which is $6.3 per month EC2 or $5.6 proportional +Comcast cost. If someone isn't supporting syncing, there's not much point +in them not turning on pruning. Even if they didn't, a desktop in the $500 +range typically comes with 1 or 2 TB of storage by default, and without +segwit or a blocksize cap increase, 3 years from now the full history will +only take up the 33% of the smaller, three year old, budget-range PC hard +drive. Even then if we assume the hard drive price declines of the last 4 +years hold steady(14%, very low compared to historical gains), 330gb of +data only works out to a proportional monthly cost of $6.20 - still +slightly smaller than his bandwidth costs, and almost entirely removable by +turning on pruning since he isn't paying to help others sync. + +I don't know how to evaluate the impacts of RAM or CPU usage, or +consequently electricity usage for a node yet. I'm open to quantifying any +of those if there's a method, but it seems absurd that ram could even +become a signficant factor given the abundance of cheap ram nowadays with +few programs needing it. CPU usage and thus electricity costs might become +a factor, I just don't know how to quantify it at various block scales. +Currently cpu usage isn't taxing any hardware that I run a node on in any +way I have been able to notice, not including the syncing process. + +> I am also solidly unconvinced that increasing the blocksize today is a +good move, even as little as SegWit does. + +The consequence of your logic that holds node operational costs down is +that transaction fees for users go up, adoption slows as various use cases +become impractical, price growth suffers, and alt coins that choose lower +fees over node cost concerns will exhibit competitive growth against +Bitcoin's crypto-currency market share. Even if you are right, that's +hardly a tradeoff not worth thoroughly investigating from every angle, the +consequences could be just as dire for Bitcoin in 10 years as it would be +if we made ourselves vulnerable. + +And even if an altcoin can't take Bitcoin's dominance by lower fees, we +will not end up with millions of home users running nodes, ever. If they +did so, that would be orders of magnitude fee market competition, and +continuing increases in price, while hardware costs decline. If +transaction fees go up from space limitations, and they go up even further +in real-world terms from price increases, while node costs decline, +eventually it will cost more to send a transaction than it does to run a +node for a full month. No home users would send transactions because the +fee costs would be higher than anything they might use Bitcoin for, and so +they would not run a node for something they don't use - Why would they? +The cost of letting the ratio between node costs and transaction costs go +in the extreme favor of node costs would be worse - Lower Bitcoin +usability, adoption, and price, without any meaningful increase in security= +. + +How do we evaluate the math on node distributions versus various attack +vectors? + + + +On Wed, Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> +> On Mar 29, 2017 9:50 AM, "Martin L=C3=ADzner via bitcoin-dev" < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> Im tending to believe, that HF is necessary evil now. +> +> +> I will firmly disagree. We know how to do a soft-fork blocksize increase. +> If it is decided that a block size increase is justified, we can do it wi= +th +> extension blocks in a way that achieves full backwards compatibility for +> all nodes. +> +> Barring a significant security motivation, there is no need to hardfork. +> +> I am also solidly unconvinced that increasing the blocksize today is a +> good move, even as little as SegWit does. It's too expensive for a home +> user to run a full node, and user-run full nodes are what provide the +> strongest defence against political manuveuring. +> +> When considering what block size is acceptable, the impact of running +> bitcoin in the background on affordable, non-dedicated home-hardware shou= +ld +> be a top consideration. +> +> Disk space I believe is the most significant problem today, with RAM bein= +g +> the second most significant problem, and finally bandwidth consumption as +> the third most important consideration. I believe that v0.14 is already t= +oo +> expensive on all three fronts, and that block size increases shouldn't be +> considered at all until the requirements are reduced (or until consumer +> hardware is better, but I believe we are talking 3-7 years of waiting if = +we +> pick that option). +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--001a114e523e788fd3054be3d6db +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">When considerin= +g what block size is acceptable, the impact of running bitcoin in the backg= +round on affordable, non-dedicated home-hardware should be a top considerat= +ion.</span><div class=3D"gmail_extra" dir=3D"auto" style=3D"font-size:12.8p= +x"><br></div><div class=3D"gmail_extra" style=3D"font-size:12.8px">Why is t= +hat a given?=C2=A0 Is there math that outlines what the risk levels are for= + various configurations of node distributions, vulnerabilities, etc?=C2=A0 = +How does one even evaluate the costs versus the benefits of node costs vers= +us transaction fees?</div><div class=3D"gmail_extra" dir=3D"auto" style=3D"= +font-size:12.8px"><br></div><div class=3D"gmail_extra" dir=3D"auto" style= +=3D"font-size:12.8px">> Disk space I believe is the most significant pro= +blem today, with RAM being the second most significant problem, and finally= + bandwidth consumption as the third most important consideration. I believe= + that v0.14 is already too expensive on all three fronts, and that block si= +ze increases shouldn't be considered at all until the requirements are = +reduced (or until consumer hardware is better, but I believe we are talking= + 3-7 years of waiting if we pick that option).<br><br>Disk space is not the= + largest cost, either today or in the future.=C2=A0 Without historical chec= +kpointing in some fashion, bandwidth costs are more than 2 orders of magnit= +ude higher cost than every other cost for full listening nodes.=C2=A0 With = +historical syncing discounted(i.e. pruned or nonlistening nodes) bandwidth = +costs are still higher than hard drive costs.<br><br><br>Today: Full listen= +ing node, 133 peers, measured 1.5 TB/mo of bandwidth consumption over two m= +ulti-day intervals. =C2=A01,500 GB/month @ ec2 low-tier prices =3D $135/mon= +th, 110 GB storage =3D $4.95.=C2=A0 Similar arguments extend to consumer ha= +rdware - Comcast broadband is ~$80/mo depending on region and comes with 1.= +0 TB cap in most regions, so $120/mo or even $80/mo would be in the same ba= +llpark.=C2=A0 A consumer-grade 2GB hard drive is $70 and will last for at l= +east 2 years, so $2.93/month if the hard drive was totally dedicated to Bit= +coin and $0.16/month if we only count the percentage that Bitcoin uses.<br>= +<br>For a non-full listening node, ~25 peers I measured around 70 GB/month = +of usage over several days, which is $6.3 per month EC2 or $5.6 proportiona= +l Comcast cost.=C2=A0 If someone isn't supporting syncing, there's = +not much point in them not turning on pruning.=C2=A0 Even if they didn'= +t, a desktop in the $500 range typically comes with 1 or 2 TB of storage by= + default, and without segwit or a blocksize cap increase, 3 years from now = +the full history will only take up the 33% of the smaller, three year old, = +budget-range PC hard drive.=C2=A0 Even then if we assume the hard drive pri= +ce declines of the last 4 years hold steady(14%, very low compared to histo= +rical gains), 330gb of data only works out to a proportional monthly cost o= +f $6.20 - still slightly smaller than his bandwidth costs, and almost entir= +ely removable by turning on pruning since he isn't paying to help other= +s sync.<br><br>I don't know how to evaluate the impacts of RAM or CPU u= +sage, or consequently electricity usage for a node yet.=C2=A0 I'm open = +to quantifying any of those if there's a method, but it seems absurd th= +at ram could even become a signficant factor given the abundance of cheap r= +am nowadays with few programs needing it.=C2=A0 CPU usage and thus electric= +ity costs might become a factor, I just don't know how to quantify it a= +t various block scales.=C2=A0 Currently cpu usage isn't taxing any hard= +ware that I run a node on in any way I have been able to notice, not includ= +ing the syncing process.<br><br>>=C2=A0<span style=3D"font-size:12.8px">= +I am also solidly unconvinced that increasing the blocksize today is a good= + move, even as little as SegWit does.</span><span style=3D"font-size:12.8px= +"><br><br>The consequence of your logic that holds node operational costs d= +own is that transaction fees for users go up, adoption slows as various use= + cases become impractical, price growth suffers, and alt coins that choose = +lower fees over node cost concerns will exhibit competitive growth against = +Bitcoin's crypto-currency market share.=C2=A0 Even if you are right, th= +at's hardly a tradeoff not worth thoroughly investigating from every an= +gle, the consequences could be just as dire for Bitcoin in 10 years as it w= +ould be if we made ourselves vulnerable.<br><br>And even if an altcoin can&= +#39;t take Bitcoin's dominance by lower fees, we will not end up with m= +illions of home users running nodes, ever.=C2=A0 If they did so, that would= + be orders of magnitude fee market competition, and continuing increases in= + price, while hardware costs decline.=C2=A0 If transaction fees go up from = +space limitations, and they go up even further in real-world terms from pri= +ce increases, while node costs decline, eventually it will cost more to sen= +d a transaction than it does to run a node for a full month.=C2=A0 No home = +users would send transactions because the fee costs would be higher than an= +ything they might use Bitcoin for, and so they would not run a node for som= +ething they don't use - Why would they?=C2=A0 The cost of letting the r= +atio between node costs and transaction costs go in the extreme favor of no= +de costs would be worse - Lower Bitcoin usability, adoption, and price, wit= +hout any meaningful increase in security.<br><br>How do we evaluate the mat= +h on node distributions versus various attack vectors?<br><br><br></span></= +div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,= + Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev <span dir=3D"ltr">&l= +t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank= +">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquot= +e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= +id;padding-left:1ex"><div dir=3D"auto"><span class=3D""><div><div class=3D"= +gmail_extra"><br><div class=3D"gmail_quote">On Mar 29, 2017 9:50 AM, "= +Martin L=C3=ADzner via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@= +lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfo= +undation.org</a>> wrote:<blockquote class=3D"m_-5625292351202753279quote= +" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><= +div dir=3D"ltr"><div>Im tending to believe, that HF is necessary evil now.= +=C2=A0</div></div></blockquote></div><br></div></div></span><div class=3D"g= +mail_extra" dir=3D"auto">I will firmly disagree. We know how to do a soft-f= +ork blocksize increase. If it is decided that a block size increase is just= +ified, we can do it with extension blocks in a way that achieves full backw= +ards compatibility for all nodes.</div><div class=3D"gmail_extra" dir=3D"au= +to"><br></div><div class=3D"gmail_extra" dir=3D"auto">Barring a significant= + security motivation, there is no need to hardfork.</div><div class=3D"gmai= +l_extra" dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">I a= +m also solidly unconvinced that increasing the blocksize today is a good mo= +ve, even as little as SegWit does. It's too expensive for a home user t= +o run a full node, and user-run full nodes are what provide the strongest d= +efence against political manuveuring.</div><div class=3D"gmail_extra" dir= +=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">When considerin= +g what block size is acceptable, the impact of running bitcoin in the backg= +round on affordable, non-dedicated home-hardware should be a top considerat= +ion.</div><div class=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"g= +mail_extra" dir=3D"auto">Disk space I believe is the most significant probl= +em today, with RAM being the second most significant problem, and finally b= +andwidth consumption as the third most important consideration. I believe t= +hat v0.14 is already too expensive on all three fronts, and that block size= + increases shouldn't be considered at all until the requirements are re= +duced (or until consumer hardware is better, but I believe we are talking 3= +-7 years of waiting if we pick that option).</div></div> +<br>______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<br></blockquote></div><br></div> + +--001a114e523e788fd3054be3d6db-- + |