summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJared Lee Richardson <jaredr26@gmail.com>2017-03-29 12:46:50 -0700
committerbitcoindev <bitcoindev@gnusha.org>2017-03-29 19:46:53 +0000
commitdd9dc88fa42e19aca275be2b93756c4fb4a2de3b (patch)
tree729e4ad958e9a78b416631352039b65ba33dc28f
parent3555b6df082b4a59c45269385aa60224bfe2bb6c (diff)
downloadpi-bitcoindev-dd9dc88fa42e19aca275be2b93756c4fb4a2de3b.tar.gz
pi-bitcoindev-dd9dc88fa42e19aca275be2b93756c4fb4a2de3b.zip
Re: [bitcoin-dev] Hard fork proposal from last week's meeting
-rw-r--r--6d/c1a4537653219473ec4763e5ac0f46ee74c531334
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">&gt;=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">&gt; 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&#39;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&#39;t supporting syncing, there&#39;s =
+not much point in them not turning on pruning.=C2=A0 Even if they didn&#39;=
+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&#39;t paying to help other=
+s sync.<br><br>I don&#39;t know how to evaluate the impacts of RAM or CPU u=
+sage, or consequently electricity usage for a node yet.=C2=A0 I&#39;m open =
+to quantifying any of those if there&#39;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&#39;t know how to quantify it a=
+t various block scales.=C2=A0 Currently cpu usage isn&#39;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>&gt;=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&#39;s crypto-currency market share.=C2=A0 Even if you are right, th=
+at&#39;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&#39;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&#39;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>&gt;</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, &quot;=
+Martin L=C3=ADzner via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@=
+lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfo=
+undation.org</a>&gt; 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&#39;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&#39;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--
+