diff options
author | Jared Lee Richardson <jaredr26@gmail.com> | 2017-03-29 15:08:33 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-03-29 22:08:37 +0000 |
commit | c552ba8be0975e2b5b3f5511b9b2ccf051897f92 (patch) | |
tree | 9a7cd21d38718149e3691b2972f2ea3601908f39 /29 | |
parent | ac126e513cf91f1412bcf5ca266ce7010e3bc98b (diff) | |
download | pi-bitcoindev-c552ba8be0975e2b5b3f5511b9b2ccf051897f92.tar.gz pi-bitcoindev-c552ba8be0975e2b5b3f5511b9b2ccf051897f92.zip |
Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Diffstat (limited to '29')
-rw-r--r-- | 29/66783125c753a501bf1dd5ffe1ff23fd413930 | 621 |
1 files changed, 621 insertions, 0 deletions
diff --git a/29/66783125c753a501bf1dd5ffe1ff23fd413930 b/29/66783125c753a501bf1dd5ffe1ff23fd413930 new file mode 100644 index 000000000..724f6f193 --- /dev/null +++ b/29/66783125c753a501bf1dd5ffe1ff23fd413930 @@ -0,0 +1,621 @@ +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 CED7DBD4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 22:08:37 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com + [209.85.213.41]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E700165 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 22:08:35 +0000 (UTC) +Received: by mail-vk0-f41.google.com with SMTP id d188so34417665vka.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 29 Mar 2017 15:08:35 -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=a2R1FDOdf4rTTQlQb++GRuPKnsCsBtf5PpF9QH32sxA=; + b=CiNHID7eRpxJwMjK/0bXfywYyOCcUdLYKE7gHh3nuRwiODHtQxVAYwcY4F1HloxZpL + ss5Bk7fKscWtrAUBdQkMweVqxJB8lJT5LrAp+E4Y121I7CFnkC6c7kZN/d7z68YS1eGR + f8SHQqMDk/fmSi6afWUKq1UAGY4FXpuU/wnYP37/Lypfl8bkL9qa58U1GQlCXLX0HbC4 + cQKkGAwwX7V6lIFicbMWGWWFZk0zx2yDT1X2sALYwA3BEzO3lRWzcC8lhT/KK8TDyixF + D8MNpY23lZCddITRoJ0pa6K0J5Wv22Lo9TLOPZDgdGkXlH88NTX+Z6nqkiEtdobbyPtm + hJgw== +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=a2R1FDOdf4rTTQlQb++GRuPKnsCsBtf5PpF9QH32sxA=; + b=jvnPw5sUfvqhKxB1ww0zHtMhFyFjs/xmmHncoyvMniozyQW1e8n9dCnMUowpDqRZ+C + KAhbEWkTTiYPK8biVxx0gesYEgCRiFfQ6ZoPUOWIIq0GbXqNK8+iPtv+kghPFpag4wN8 + Z2WC2z9kIjU9ZpLE31c1/odtCo+ZYTr6o5esGe8tCDTu2+9Uj72q6ByIrFzo3cgh5/jX + dt8D1Vw24wBkcOqeYnux/KJI5ulx1xCG4ZF8B4fDvShXPZi+hRZ6DB9hfIo0pmrAhHqa + FD95D7TK0PjNeHtYpBXWIjc649gyuDgOYrklfsh9uGCw5GFCIeJfaVZQqzEeiERigqq4 + AuOw== +X-Gm-Message-State: AFeK/H3SwQPA2dm7fjJkG1KidTHmTcHEERfhhJEC92fiXneNmZm+5GPSym6fdM+W+fCYSHxWiH6MD7xRrH7Z3w== +X-Received: by 10.176.3.210 with SMTP id 76mr1380459uau.66.1490825314481; Wed, + 29 Mar 2017 15:08:34 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 15:08:33 -0700 (PDT) +In-Reply-To: <CAFVRnyq9Qgw88RZqenjQTDZHEWeuNCdh12Dq7wCGZdu9ZuEN9w@mail.gmail.com> +References: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com> + <CAFVRnyq9Qgw88RZqenjQTDZHEWeuNCdh12Dq7wCGZdu9ZuEN9w@mail.gmail.com> +From: Jared Lee Richardson <jaredr26@gmail.com> +Date: Wed, 29 Mar 2017 15:08:33 -0700 +Message-ID: <CAD1TkXvd4yLHZDAdMi78WwJ_siO1Vt7=DgYiBmP45ffVveuHBg@mail.gmail.com> +To: David Vorick <david.vorick@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=94eb2c0740fc4abe8e054be5d1e6 +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 22:13:39 +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 22:08:38 -0000 + +--94eb2c0740fc4abe8e054be5d1e6 +Content-Type: text/plain; charset=UTF-8 + +> It's a political assessment. Full nodes are the ultimate arbiters of +consensus. + +That's not true unless miners are thought of as the identical to nodes, +which is has not been true for nearly 4 years now. Nodes arbitrating a +consensus the BU theory - that nodes can restrain miners - but it doesn't +work. If miners were forked off from nonminers, the miner network could +keep their blockchain operational under attack from the nodes far better +than nodes could keep their blockchain operational under attack from the +miners. The miners could effectively grind the node network to a complete +halt and probably still run their own fork unimpeded at the same time. +This would continue until the the lack of faith in the network drove the +miners out of business economically, or until the node network capitulated +and followed the rules of the miner network. + +The reason BU isn't a dire threat is that there's a great rift between the +miners just like there is between the average users, just as satoshi +intended, and that rift gives the user network the economic edge. + +> 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. + +I think you're conflating mining with node operation here. Node users only +power is to block the propagation of certain things. Since miners also +have a node endpoint, they can cut the node users out of the equation by +linking with eachother directly - something they already do out of +practicality for propagation. Node users do not have the power to +arbitrate consensus, that is why we have blocks and PoW. + +> 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. [..] that changes you are opposed to +are not introduced into the network. + +This isn't true. Non-miner nodes cannot produce blocks. Their opinion is +not represented in the blockchain in any way, the blockchain is entirely +made up of blocks. They can commit transactions, but the transactions must +follow an even stricter set of rules and short of a user activated PoW +change, the miners get to decide. It might be viable for us to introduce +ways for transactions to vote on things, but that also isn't nodes voting - +that's money voting. + +Bitcoin is structured such that nodes have no votes because nodes cannot be +trusted. They don't inherently represent individuals, they don't +inherently represent value, and they don't commit work that is played +against eachother to achieve a game theory equilibrium. That's miners. + +> 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. + +Your assumption is predicated upon the idea that users pay a fixed cost for +any volume of bandwidth. That assertion is true for some users but not +true for others, and it is becoming exceedingly less true in recent years +with the addition of bandwidth caps by many ISP's. Even users without a +bandwidth cap can often get a very threatening letter if they were to max +their connection 24/7. Assuming unlimited user bandwidth in the future and +comparing that with limited datacenter bandwidth is extremely short +sighted. Fundamentally, if market forces have established that datacenter +bandwidth costs $0.09 per GB, what makes you think that ISP's don't have to +deal with the same limitations? They do, the difference is that $0.09 per +GB times the total usage across the ISP's customer base is far, far lower +than $80 times the number of customers. The more that a small group of +customers deviating wildly becomes a problem for them, the more they will +add bandwidth caps or send threatening letters or even rate-limit or stop +serving those users. + +Without that assumption, your math and examples fall apart - Bandwidth +costs for full archival nodes are nearly 50 times higher than storage costs +no matter whether they are at home or in a datacenter. + +> The financials of home nodes follow a completely different math than the +costs you are citing by quoting datacenter prices. + +No, they really aren't without your assumption. Yes, they are somewhat +different - If someone has a 2TB hard drive but only ever uses 40% of it, +the remaining hard drive space would have a cost of zero. Those specific +examples break down when you average over several years and fifty thousand +users. If that same user was running a bitcoin node and hard drive space +was indeed a concern, they would factor that desire into the purchase of +their next computer, preferring those with larger hard drives. That +reintroduces the cost with the same individual who had no cost before. The +cost difference doesn't work out to the exact same numbers as the +datacenter costs, who have a better economy of scale but also have profit +and business overhead, but all of the math I've done indicates that over +thousands of individuals and several years of time, the costs land in the +same ballpark. For example - Comcast bandwidth cap = 1000gb @ ~$80/month. + $0.08/GB. Amazon's first tier is currently $0.09. Much closer than I +even expected before I worked out the math. I'm open to being proven wrong. + +> 0.14 uses more than 1 GB of RAM. + +I'm running 0.13.2 and only see 300 mb of ram. Why is 0.14 using three +times the ram? + +> 1GB I think is really the limit you'd want to have before you'd start +seeing users choose not to run nodes simply + +Again, while I sympathize with the concept, I don't believe holding the +growth of the entire currency back based on minimum specs is a fair +tradeoff. The impact on usecases that depend on a given fee level is total +obliteration. That's unavoidable for things like microtransactions, but a +fee level of $1/tx allows for hundreds of opportunities that a fee level of +$100/tx does not. That difference may be the deciding factor in the +network effect between Bitcoin and a competitor altcoin. Bitcoin dying out +because a better-operated coin steals its first-mover advantage is just as +bad as bitcoin dying out because an attacker halted tx propagation and +killed the network. Probably even worse - First mover advantages are +almost never retaken, but the network could recover from a peering attack +with software changes and community/miner responses. + +> However, I think the fees would have to get in the $50 range for that to +start to be the case. + +I calculated this out. If blocksizes aren't increased, but price increases +continue as they have in the last 3-5 years, per-node operational costs for +one month drop from roughly $10-15ish (using datacenter numbers, which you +said would be higher than home user numbers and might very well be when +amortized thoroughly) down to $5-8 in less than 8 years. If transaction +fees don't rise at all due to blockspace competition (i.e., they offset +only the minimum required for miners to economically protect Bitcoin), +they'll be above $10 in less than 4 years. I believe that comparing +1-month of node operational costs versus 1 transaction fee is a reasonable, +albeit imperfect, comparison of when users will stop caring. + +That's not very far in the future at all, and fee-market competition will +probably be much, much worse for us and better for miners. + +> 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), + +So I don't mean to be rude here, but this kind of thinking is very poor +logic when applied to anyone who isn't already a libertarian Bitcoin +supporter. By anyone outside the Bitcoin world's estimation, Bitcoin is an +extremely high risk, unreliable store of value. We like to compare it to +"digital gold" because of the parameters that Satoshi chose, but saying it +does not make it true. For someone not already a believer, Bitcoin is a +risky, speculative investment into a promising future technology, and gold +is a stable physical asset with 4,000 years of acceptance history that has +the same value in nearly every city on the planet. Bitcoin is difficult to +purchase and difficult to find someone to exchange for goods or services. + +Could Bitcoin become more like what you described in the future? A lot of +us hope so or we wouldn't be here right now. But in the meantime, any +other crypto currency that choses parameters similar to gold could eclipse +Bitcoin if we falter. If their currency is more usable because they +balance the ratio of node operational costs/security versus transaction +fees/usability, they have a pretty reasonable chance of doing so. And then +you won't store your $10k+ in bitcoin, you'll store in $altcoin. The +market doesn't really care who wins. + +> 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. + +That's nothing, we've never had any fee competition at all until basically +November of last year. From December to March transaction fees went up by +250%, and they doubled from May to December before that. Transactions per +year are up 80% per year for the last 4 years. Things are about to get +screwed. + + +On Wed, Mar 29, 2017 at 1:28 PM, David Vorick via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> > > 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. +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--94eb2c0740fc4abe8e054be5d1e6 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><br><br>>=C2=A0<span style=3D"font-size:12.8px">It'= +s a political assessment. Full nodes are the ultimate arbiters of consensus= +.=C2=A0<br><br>That's not true unless miners are thought of as the iden= +tical to nodes, which is has not been true for nearly 4 years now.=C2=A0 No= +des arbitrating a consensus the BU theory - that nodes can restrain miners = +- but it doesn't work.=C2=A0 If miners were forked off from nonminers, = +the miner network could keep their blockchain operational under attack from= + the nodes far better than nodes could keep their blockchain operational un= +der attack from the miners.=C2=A0 The miners could effectively grind the no= +de network to a complete halt and probably still run their own fork unimped= +ed at the same time.=C2=A0 This would continue until the the lack of faith = +in the network drove the miners out of business economically, or until the = +node network capitulated and followed the rules of the miner network.<br><b= +r>The reason BU isn't a dire threat is that there's a great rift be= +tween the miners just like there is between the average users, just as sato= +shi intended, and that rift gives the user network the economic edge.<br><b= +r>>=C2=A0</span><span style=3D"font-size:12.8px">If home users are not r= +unning their own full nodes, then home users have to trust and rely on othe= +r, more powerful nodes to represent them. Of course, the more powerful node= +s, simply by nature of having more power, are going to have different opini= +ons and objectives from the users.<br><br>I think you're conflating min= +ing with node operation here.=C2=A0 Node users only power is to block the p= +ropagation of certain things.=C2=A0 Since miners also have a node endpoint,= + they can cut the node users out of the equation by linking with eachother = +directly - something they already do out of practicality for propagation.= +=C2=A0 Node users do not have the power to arbitrate consensus, that is why= + we have blocks and PoW.<br><br>>=C2=A0</span><span style=3D"font-size:1= +2.8px">And it's impossible for 5000 nodes to properly represent the vie= +ws of 5,000,000 users. Users running full nodes is important to prevent pol= +itical hijacking of the Bitcoin protocol. =C2=A0[..]=C2=A0</span><span styl= +e=3D"font-size:12.8px">that changes you are opposed to are not introduced i= +nto the network.</span><span style=3D"font-size:12.8px"><br><br>This isn= +9;t true.=C2=A0 Non-miner nodes cannot produce blocks.=C2=A0 Their opinion = +is not represented in the blockchain in any way, the blockchain is entirely= + made up of blocks.=C2=A0 They can commit transactions, but the transaction= +s must follow an even stricter set of rules and short of a user activated P= +oW change, the miners get to decide.=C2=A0 It might be viable for us to int= +roduce ways for transactions to vote on things, but that also isn't nod= +es voting - that's money voting.<br><br>Bitcoin is structured such that= + nodes have no votes because nodes cannot be trusted.=C2=A0 They don't = +inherently represent individuals, they don't inherently represent value= +, and they don't commit work that is played against eachother to achiev= +e a game theory equilibrium.=C2=A0 That's miners.</span><div><span styl= +e=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8p= +x">>=C2=A0</span><span style=3D"font-size:12.8px">This statement is not = +true for home users, it is true for datacenter nodes. For home users, 200 G= +B of bandwidth and 500 GB of bandwidth largely have the exact same cost.<br= +><br>Your assumption is predicated upon the idea that users pay a fixed cos= +t for any volume of bandwidth.=C2=A0 That assertion is true for some users = +but not true for others, and it is becoming exceedingly less true in recent= + years with the addition of bandwidth caps by many ISP's.=C2=A0 Even us= +ers without a bandwidth cap can often get a very threatening letter if they= + were to max their connection 24/7.=C2=A0 Assuming unlimited user bandwidth= + in the future and comparing that with limited datacenter bandwidth is extr= +emely short sighted.=C2=A0 Fundamentally, if market forces have established= + that datacenter bandwidth costs $0.09 per GB, what makes you think that IS= +P's don't have to deal with the same limitations?=C2=A0 They do, th= +e difference is that $0.09 per GB times the total usage across the ISP'= +s customer base is far, far lower than $80 times the number of customers.= +=C2=A0 The more that a small group of customers deviating wildly becomes a = +problem for them, the more they will add bandwidth caps or send threatening= + letters or even rate-limit or stop serving those users.</span></div><div><= +span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s= +ize:12.8px">Without that assumption, your math and examples fall apart - Ba= +ndwidth costs for full archival nodes are nearly 50 times higher than stora= +ge costs no matter whether they are at home or in a datacenter.</span></div= +><div><span style=3D"font-size:12.8px"><br>>=C2=A0</span><span style=3D"= +font-size:12.8px">The financials of home nodes follow a completely differen= +t math than the costs you are citing by quoting datacenter prices.<br></spa= +n><span style=3D"font-size:12.8px"><br>No, they really aren't without y= +our assumption.=C2=A0 Yes, they are somewhat different - If someone has a 2= +TB hard drive but only ever uses 40% of it, the remaining hard drive space = +would have a cost of zero.=C2=A0 Those specific examples break down when yo= +u average over several years and fifty thousand users.=C2=A0 If that same u= +ser was running a bitcoin node and hard drive space was indeed a concern, t= +hey would factor that desire into the purchase of their next computer, pref= +erring those with larger hard drives.=C2=A0 That reintroduces the cost with= + the same individual who had no cost before.=C2=A0 The cost difference does= +n't work out to the exact same numbers as the datacenter costs, who hav= +e a better economy of scale but also have profit and business overhead, but= + all of the math I've done indicates that over thousands of individuals= + and several years of time, the costs land in the same ballpark.=C2=A0 For = +example - Comcast bandwidth cap =3D 1000gb @ ~$80/month. =C2=A0$0.08/GB.=C2= +=A0 Amazon's first tier is currently $0.09.=C2=A0 Much closer than I ev= +en expected before I worked out the math.=C2=A0 I'm open to being prove= +n wrong.<br><br>>=C2=A0</span><span style=3D"font-size:12.8px">0.14 uses= + more than 1 GB of RAM.<br></span><span style=3D"font-size:12.8px"><br>I= +9;m running 0.13.2 and only see 300 mb of ram.=C2=A0 Why is 0.14 using thre= +e times the ram?</span></div><div><span style=3D"font-size:12.8px"><br></sp= +an></div><div><span style=3D"font-size:12.8px">>=C2=A0</span><span style= +=3D"font-size:12.8px">1GB I think is really the limit you'd want to hav= +e before you'd start seeing users choose not to run nodes simply<br></s= +pan><br><span style=3D"font-size:12.8px">Again, while I sympathize=C2=A0wit= +h the concept, I don't believe holding the growth of the entire currenc= +y back based on minimum specs is a fair tradeoff.=C2=A0 The impact on useca= +ses that depend on a given fee level is total obliteration.=C2=A0 That'= +s unavoidable for things like microtransactions, but a fee level of $1/tx a= +llows for hundreds of opportunities that a fee level of $100/tx does not.= +=C2=A0 That difference may be the deciding factor in the network effect bet= +ween Bitcoin and a competitor altcoin.=C2=A0 Bitcoin dying out because a be= +tter-operated coin steals its first-mover advantage is just as bad as bitco= +in dying out because an attacker halted tx propagation and killed the netwo= +rk.=C2=A0 Probably even worse - First mover advantages are almost never ret= +aken, but the network could recover from a peering attack with software cha= +nges and community/miner responses.</span><br><br>>=C2=A0<span style=3D"= +font-size:12.8px">However, I think the fees would have to get in the $50 ra= +nge for that to start to be the case.=C2=A0</span><br><br>I calculated this= + out.=C2=A0 If blocksizes aren't increased, but price increases continu= +e as they have in the last 3-5 years, per-node operational costs for one mo= +nth drop from roughly $10-15ish (using datacenter numbers, which you said w= +ould be higher than home user numbers and might very well be when amortized= + thoroughly) down to $5-8 in less than 8 years.=C2=A0 If transaction fees d= +on't rise at all due to blockspace competition (i.e., they offset only = +the minimum required for miners to economically protect Bitcoin), they'= +ll be above $10 in less than 4 years.=C2=A0 I believe that comparing 1-mont= +h of node operational costs versus 1 transaction fee is a reasonable, albei= +t imperfect, comparison of when users will stop caring.<br><br>That's n= +ot very far in the future at all, and fee-market competition will probably = +be much, much worse for us and better for miners.<br><br>>=C2=A0<span st= +yle=3D"font-size:12.8px">When talking about emergency funds - that is, $10k= ++ that you keep in case your government defaults, hyperinflates, seizes cit= +izen assets, etc. etc. (situations that many Bitcoin users today have to le= +gitimately worry about),<br></span><br>So I don't mean to be rude here,= + but this kind of thinking is very poor logic when applied to anyone who is= +n't already a libertarian Bitcoin supporter.=C2=A0 By anyone outside th= +e Bitcoin world's estimation, Bitcoin is an extremely high risk, unreli= +able store of value.=C2=A0 We like to compare it to "digital gold"= +; because of the parameters that Satoshi chose, but saying it does not make= + it true.=C2=A0 For someone not already a believer, Bitcoin is a risky, spe= +culative investment into a promising future technology, and gold is a stabl= +e physical asset with 4,000 years of acceptance history that has the same v= +alue in nearly every city on the planet.=C2=A0 Bitcoin is difficult to purc= +hase and difficult to find someone to exchange for goods or services.<br><b= +r>Could Bitcoin become more like what you described in the future?=C2=A0 A = +lot of us hope so or we wouldn't be here right now.=C2=A0 But in the me= +antime, any other crypto currency that choses parameters similar to gold co= +uld eclipse Bitcoin if we falter.=C2=A0 If their currency is more usable be= +cause they balance the ratio of node operational costs/security versus tran= +saction fees/usability, they have a pretty reasonable chance of doing so.= +=C2=A0 And then you won't store your $10k+ in bitcoin, you'll store= + in $altcoin.=C2=A0 The market doesn't really care who wins.<br><br>>= +;=C2=A0<span style=3D"font-size:12.8px">We are two orders of magnitude away= + from this type of fee pressure, so I think it continues to make sense to b= +e considering the home nodes as the target that we want to hit.<br></span><= +br>That's nothing, we've never had any fee competition at all until= + basically November of last year.=C2=A0 From December to March transaction = +fees went up by 250%, and they doubled from May to December before that.=C2= +=A0 Transactions per year are up 80% per year for the last 4 years.=C2=A0 T= +hings are about to get screwed.<br><br></div></div><div class=3D"gmail_extr= +a"><br><div class=3D"gmail_quote">On Wed, Mar 29, 2017 at 1:28 PM, David Vo= +rick via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@li= +sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio= +n.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= +argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l= +tr"><span class=3D"">> <span class=3D"m_5779025606995714197gmail-im">>= +;=C2=A0<span style=3D"font-size:12.8px">When 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.</span><div style=3D"font-size:12.8px" dir=3D"auto" class=3D"= +gmail_extra"><br></div></span><div style=3D"font-size:12.8px" class=3D"gmai= +l_extra">> 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?</div><div style=3D"font-size:12.8px" dir=3D"auto" = +class=3D"gmail_extra"><br></div></span><div style=3D"font-size:12.8px" clas= +s=3D"gmail_extra">It's a political assessment. Full nodes are the ultim= +ate arbiters of consensus. When a contentious change is suggested, only the= + full nodes have the power to either accept or reject this contentious chan= +ge. If home users are not running their own full nodes, then home users hav= +e to trust and rely on other, more powerful nodes to represent them. Of cou= +rse, the more powerful nodes, simply by nature of having more power, are go= +ing 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 user= +s. Users running full nodes is important to prevent political hijacking of = +the Bitcoin protocol. Running a full node yourself is the only way to guara= +ntee (in the absence of trust - which Bitcoin is all about eliminating trus= +t) that changes you are opposed to are not introduced into the network.<spa= +n class=3D""><br><br>> <span class=3D"m_5779025606995714197gmail-im"></s= +pan>Disk space is not the largest cost, either=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. <br><br></span></div><div = +style=3D"font-size:12.8px" class=3D"gmail_extra">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 id= +entical to if I use 200 GB. So long as bandwidth is kept under my home band= +width cap, bandwidth for home nodes is _free_.<br><br>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 clos= +er to $200 than to $2. And if I go out and buy an extra drive to support Bi= +tcoin, it's going to cost about $50 no matter what drive I pick, becaus= +e 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 ex= +plicitly so I could run a bitcoin node.<br><br></div><div style=3D"font-siz= +e:12.8px" class=3D"gmail_extra">The financials of home nodes follow a compl= +etely different math than the costs you are citing by quoting datacenter pr= +ices.<span class=3D""><br><br>> I don't know how to evaluate the imp= +acts of RAM or CPU usage, 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.<br><br></span></div><div style=3D"fo= +nt-size:12.8px" class=3D"gmail_extra">Many home machines only have 4GB of R= +AM. (I am acutely aware of this because my own software consumes about 3.5G= +B 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 thin= +k 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 p= +rograms open at the same time. 1GB I think is really the limit you'd wa= +nt to have before you'd start seeing users choose not to run nodes simp= +ly because they'd rather have 300 tabs open instead.<br><br></div><div = +style=3D"font-size:12.8px" class=3D"gmail_extra">CPU usage I think is prett= +y minimal. Your node is pretty busy during IBD which is annoying but tolera= +ble. And during normal usage a user isn't even going to notice. Same fo= +r electricity. They aren't going to notice at the end of the month if t= +heir electricity bill is a dollar higher because of Bitcoin.<span class=3D"= +"><br><br>> <span style=3D"font-size:12.8px">The consequence of your log= +ic 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 <span class=3D"m_5779025606995714197gmail-aBn"><sp= +an class=3D"m_5779025606995714197gmail-aQJ">in 10 years</span></span> as it= + would be if we made ourselves vulnerable.<br><br></span></span></div><div = +style=3D"font-size:12.8px" class=3D"gmail_extra"><span style=3D"font-size:1= +2.8px">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 hardwar= +e for Bitcoin (a dedicated node or whatever), then there is no longer a rea= +son to worry about these people as users. However, I think the fees would h= +ave 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 governmen= +t defaults, hyperinflates, seizes citizen assets, etc. etc. (situations tha= +t 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 fee= +s on a home node may be $150 / yr, while the cost of dedicated hardware mig= +ht be $150/yr ($600 box amortized over 4 years). We are two orders of magni= +tude away from this type of fee pressure, so I think it continues to make s= +ense to be considering the home nodes as the target that we want to hit.<br= +><br>>=C2=A0 </span>What about periodically committing the entire UTXO s= +et=20 +to a special checkpoint block which becomes the new de facto Genesis=20 +block? <br><div dir=3D"auto"><br></div></div><div style=3D"font-size:12.8px= +" class=3D"gmail_extra">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.<br></div><div style=3D= +"font-size:12.8px" class=3D"gmail_extra"><br></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> + +--94eb2c0740fc4abe8e054be5d1e6-- + |