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 CED7DBD4 for ; 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 ; Wed, 29 Mar 2017 22:08:35 +0000 (UTC) Received: by mail-vk0-f41.google.com with SMTP id d188so34417665vka.0 for ; 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: References: From: Jared Lee Richardson Date: Wed, 29 Mar 2017 15:08:33 -0700 Message-ID: To: David Vorick , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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


>=C2=A0It'= s a political assessment. Full nodes are the ultimate arbiters of consensus= .=C2=A0

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

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.

>=C2=A0And 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=A0that changes you are opposed to are not introduced i= nto the network.

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.

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.

>=C2=A0This 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.
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 style=3D"font-size: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.

>=C2=A0The financials of home nodes follow a completely differen= t math than the costs you are citing by quoting datacenter prices.

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.

>=C2=A00.14 uses= more than 1 GB of RAM.

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?

>=C2=A01GB I think is really the limit you'd want to hav= e before you'd start seeing users choose not to run nodes simply

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.

>=C2=A0However, I think the fees would have to get in the $50 ra= nge for that to start to be the case.=C2=A0

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.

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.

>=C2=A0When 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),

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

>= ;=C2=A0We 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>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.


On Wed, Mar 29, 2017 at 1:28 PM, David Vo= rick via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
> >= ;=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 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.

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

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

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.

The financials of home nodes follow a compl= etely different math than the costs you are citing by quoting datacenter pr= ices.

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

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.

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.

> 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 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 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.
>=C2=A0 What about periodically committing the entire UTXO s= et=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.


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


--94eb2c0740fc4abe8e054be5d1e6--