From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A519BDE for ; 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 ; Wed, 29 Mar 2017 19:46:52 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id r69so30611497vke.2 for ; 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: References: From: Jared Lee Richardson Date: Wed, 29 Mar 2017 12:46:50 -0700 Message-ID: To: David Vorick , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
>=C2=A0When 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.

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?

> 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).

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.


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.
=
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.

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.

>=C2=A0= 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 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.

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.

How do we evaluate the mat= h on node distributions versus various attack vectors?



On Wed,= Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:

On Mar 29, 2017 9:50 AM, "= Martin L=C3=ADzner via bitcoin-dev" <bitcoin-dev@lists.linuxfo= undation.org> wrote:
<= div dir=3D"ltr">
Im tending to believe, that HF is necessary evil now.= =C2=A0

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.

Barring a significant= security motivation, there is no need to hardfork.

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.

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.

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).

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a114e523e788fd3054be3d6db--