Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F2DDABAA for ; Wed, 29 Mar 2017 20:28:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1BF6B0 for ; Wed, 29 Mar 2017 20:28:37 +0000 (UTC) Received: by mail-wr0-f170.google.com with SMTP id w43so31795735wrb.0 for ; Wed, 29 Mar 2017 13:28:37 -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=v6Uqb8Zr0yLTJ/nnD8F+FllL+XRhNUArPbJTVPd2jr0=; b=LwRp5lFYyWqEv48gZsHZfhPow8VdYBXoNUXp8hjUtbZRbVa21lSaxULL1gX4PlZha2 uFLkWZTshzczQ7in2//ZUo4IRZoeVo4CLYnTnIn6C0PG36DZG8LLRO0RBTpdH9CYfC+w 3BbKS/kRynnMLDDtGhWMTooCuGZtXZhMr/lEki652uv7IeEUXcezFZKrMt+g2HFYWK4Q myF0j1eQ74qSaI9BwQmtlB+ZOuHNoVhz0ZAyFSkRaz0mdisMTlL/UDipfKoQkBt34A94 4KhDf/TKgrRzrhh/FEHohePSUbt8FHZKaQLDa3foJCrBaLMbgiPW1+fxL/jEjvegktbh MRYg== 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=v6Uqb8Zr0yLTJ/nnD8F+FllL+XRhNUArPbJTVPd2jr0=; b=EqO+RLSXovAxOWWcVhVdIy2Suysnxvzz8Y8OIcJMVBg8s5nwdlghyyIwkc55bYCsql n43E45Irybp2+CQdFh1sW6pojRX5ZRETJnSZhFUZ3vC//37OqPfQtZRZcccGF8vGmkyV /bJGql5LiFeqNkRRp4ID2r7D7FQOXKaDPGey8xXuQj6OcgRGhhPuF60b5kW0ypVDDFeN QVXWMUWQs1pLOBTJ5SFx8u9N7N/iewIqKzST/nLOWWqnCTLXxkSYE9J3ePxX1anwz73U o/7eZ9F//Q3cS27T9qmYzvU9l3opRx3xPnoBshjKD+rp2n4f9L51KVDmZC8l5nfXgLJc gsVQ== X-Gm-Message-State: AFeK/H1oIPOJGQMCgCHmJslSsrVGpsbdVeNWigwPdwoJOoBh+opXjlCiyX5Ml/Wr2sOWyThGpZxkVVyex/gnOw== X-Received: by 10.223.148.102 with SMTP id 93mr2017443wrq.144.1490819316053; Wed, 29 Mar 2017 13:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.55.9 with HTTP; Wed, 29 Mar 2017 13:28:35 -0700 (PDT) In-Reply-To: References: From: David Vorick Date: Wed, 29 Mar 2017 16:28:35 -0400 Message-ID: To: Daniele Pinna , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c0d2574c20008054be46beb X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 20:28:39 -0000 --94eb2c0d2574c20008054be46beb Content-Type: text/plain; charset=UTF-8 > > 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? It's a political assessment. Full nodes are the ultimate arbiters of consensus. When a contentious change is suggested, only the full nodes have the power to either accept or reject this contentious change. If home users are not running their own full nodes, then home users have to trust and rely on other, more powerful nodes to represent them. Of course, the more powerful nodes, simply by nature of having more power, are going to have different opinions and objectives from the users. And it's impossible for 5000 nodes to properly represent the views of 5,000,000 users. Users running full nodes is important to prevent political hijacking of the Bitcoin protocol. Running a full node yourself is the only way to guarantee (in the absence of trust - which Bitcoin is all about eliminating trust) that changes you are opposed to are not introduced into the network. > 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. This statement is not true for home users, it is true for datacenter nodes. For home users, 200 GB of bandwidth and 500 GB of bandwidth largely have the exact same cost. I pay a fixed amount of money for my internet, and if I use 500 GB the cost is identical to if I use 200 GB. So long as bandwidth is kept under my home bandwidth cap, bandwidth for home nodes is _free_. Similarly, disk space may only be $2/TB in bulk, but as a home user I have a $1000 computer with 500 GB of total storage, 100 GB seems (psychologically) to cost a lot closer to $200 than to $2. And if I go out and buy an extra drive to support Bitcoin, it's going to cost about $50 no matter what drive I pick, because that's just how much you have to spend to get a drive. The fact that I get an extra 900 GB that I'm not using is irrelevant - I spent $50 explicitly so I could run a bitcoin node. The financials of home nodes follow a completely different math than the costs you are citing by quoting datacenter prices. > 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. Many home machines only have 4GB of RAM. (I am acutely aware of this because my own software consumes about 3.5GB of RAM, which means all of our users stuck at 4 GB cannot use my software and Chrome at the same time). 0.14 uses more than 1 GB of RAM. This I think is not really a problem for most people, but it becomes a problem if the amount of RAM required grows enough that they can't have all of their programs open at the same time. 1GB I think is really the limit you'd want to have before you'd start seeing users choose not to run nodes simply because they'd rather have 300 tabs open instead. CPU usage I think is pretty minimal. Your node is pretty busy during IBD which is annoying but tolerable. And during normal usage a user isn't even going to notice. Same for electricity. They aren't going to notice at the end of the month if their electricity bill is a dollar higher because of Bitcoin. > 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. This is very much worth considering. If transaction fees are so high that there is no use case at all for people unwilling to buy extra hardware for Bitcoin (a dedicated node or whatever), then there is no longer a reason to worry about these people as users. However, I think the fees would have to get in the $50 range for that to start to be the case. When talking about emergency funds - that is, $10k+ that you keep in case your government defaults, hyperinflates, seizes citizen assets, etc. etc. (situations that many Bitcoin users today have to legitimately worry about), then you are going to be making a few transactions per year at most, and the cost of fees on a home node may be $150 / yr, while the cost of dedicated hardware might be $150/yr ($600 box amortized over 4 years). We are two orders of magnitude away from this type of fee pressure, so I think it continues to make sense to be considering the home nodes as the target that we want to hit. > What about periodically committing the entire UTXO set to a special checkpoint block which becomes the new de facto Genesis block? This should be discussed in another thread but I don't think I'm alone in saying that I think this could actually be done in a secure / safe / valuable way if you did it correctly. It would reduce bandwidth pressure on archive nodes, reduce disk pressure on full nodes, and imo make for a more efficient network overall. --94eb2c0d2574c20008054be46beb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> >=C2=A0When considering=20 what block size is acceptable, the impact of running bitcoin in the=20 background on affordable, non-dedicated home-hardware should be a top=20 consideration.

> Why is that a given?=C2=A0 Is there math that outlines what the risk levels ar= e=20 for various configurations of node distributions, vulnerabilities, etc?=C2= =A0 How does one even evaluate the costs versus the benefits of node costs=20 versus transaction fees?

It's a political assessment. Full nodes are the ultimate arb= iters of consensus. When a contentious change is suggested, only the full n= odes have the power to either accept or reject this contentious change. If = home users are not running their own full nodes, then home users have to tr= ust and rely on other, more powerful nodes to represent them. Of course, th= e more powerful nodes, simply by nature of having more power, are going to = have different opinions and objectives from the users. And it's impossi= ble for 5000 nodes to properly represent the views of 5,000,000 users. User= s running full nodes is important to prevent political hijacking of the Bit= coin protocol. Running a full node yourself is the only way to guarantee (i= n the absence of trust - which Bitcoin is all about eliminating trust) that= changes you are opposed to are not introduced into the network.

>= ; Disk space is not the largest cost, eithe= r=20 today or in the future.=C2=A0 Without historical checkpointing in some=20 fashion, bandwidth costs are more than 2 orders of magnitude higher cost than every other cost for full listening nodes.

This statement is not true for = home users, it is true for datacenter nodes. For home users, 200 GB of band= width and 500 GB of bandwidth largely have the exact same cost. I pay a fix= ed amount of money for my internet, and if I use 500 GB the cost is identic= al to if I use 200 GB. So long as bandwidth is kept under my home bandwidth= cap, bandwidth for home nodes is _free_.

Similarly, disk space may = only be $2/TB in bulk, but as a home user I have a $1000 computer with 500 = GB of total storage, 100 GB seems (psychologically) to cost a lot closer to= $200 than to $2. And if I go out and buy an extra drive to support Bitcoin= , it's going to cost about $50 no matter what drive I pick, because tha= t's just how much you have to spend to get a drive. The fact that I get= an extra 900 GB that I'm not using is irrelevant - I spent $50 explici= tly so I could run a bitcoin node.

The financials of home nodes follow a completely= different math than the costs you are citing by quoting datacenter prices.=

> I don't know how to evaluate the impacts of RAM or CPU usa= ge, or=20 consequently electricity usage for a node yet.=C2=A0 I'm open to quanti= fying=20 any of those if there's a method, but it seems absurd that ram could=20 even become a signficant factor given the abundance of cheap ram=20 nowadays with few programs needing it.

Many home machines only have 4GB of RAM. (I = am acutely aware of this because my own software consumes about 3.5GB of RA= M, which means all of our users stuck at 4 GB cannot use my software and Ch= rome at the same time). 0.14 uses more than 1 GB of RAM. This I think is no= t really a problem for most people, but it becomes a problem if the amount = of RAM required grows enough that they can't have all of their programs= open at the same time. 1GB I think is really the limit you'd want to h= ave before you'd start seeing users choose not to run nodes simply beca= use they'd rather have 300 tabs open instead.

CPU usage I think is pretty min= imal. Your node is pretty busy during IBD which is annoying but tolerable. = And during normal usage a user isn't even going to notice. Same for ele= ctricity. They aren't going to notice at the end of the month if their = electricity bill is a dollar higher because of Bitcoin.

> The consequence of your logic that holds=20 node operational costs down is that transaction fees for users go up,=20 adoption slows as various use cases become impractical, price growth=20 suffers, and alt coins that choose lower fees over node cost concerns=20 will exhibit competitive growth against Bitcoin's crypto-currency marke= t share.=C2=A0 Even if you are right, that's hardly a tradeoff not worth= =20 thoroughly investigating from every angle, the consequences could be=20 just as dire for Bitcoin in 10 years as it would be if we made oursel= ves vulnerable.

This is very much worth c= onsidering. If transaction fees are so high that there is no use case at al= l for people unwilling to buy extra hardware for Bitcoin (a dedicated node = or whatever), then there is no longer a reason to worry about these people = as users. However, I think the fees would have to get in the $50 range for = that to start to be the case. When talking about emergency funds - that is,= $10k+ that you keep in case your government defaults, hyperinflates, seize= s citizen assets, etc. etc. (situations that many Bitcoin users today have = to legitimately worry about), then you are going to be making a few transac= tions per year at most, and the cost of fees on a home node may be $150 / y= r, while the cost of dedicated hardware might be $150/yr ($600 box amortize= d over 4 years). We are two orders of magnitude away from this type of fee = pressure, so I think it continues to make sense to be considering the home = nodes as the target that we want to hit.

>=C2=A0 What abou= t periodically committing the entire UTXO set=20 to a special checkpoint block which becomes the new de facto Genesis=20 block?

This should be discussed in another thread but I do= n't think I'm alone in saying that I think this could actually be d= one in a secure / safe / valuable way if you did it correctly. It would red= uce bandwidth pressure on archive nodes, reduce disk pressure on full nodes= , and imo make for a more efficient network overall.

--94eb2c0d2574c20008054be46beb--