summaryrefslogtreecommitdiff
path: root/29
diff options
context:
space:
mode:
authorJared Lee Richardson <jaredr26@gmail.com>2017-03-29 15:08:33 -0700
committerbitcoindev <bitcoindev@gnusha.org>2017-03-29 22:08:37 +0000
commitc552ba8be0975e2b5b3f5511b9b2ccf051897f92 (patch)
tree9a7cd21d38718149e3691b2972f2ea3601908f39 /29
parentac126e513cf91f1412bcf5ca266ce7010e3bc98b (diff)
downloadpi-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/66783125c753a501bf1dd5ffe1ff23fd413930621
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>&gt;=C2=A0<span style=3D"font-size:12.8px">It&#39;=
+s a political assessment. Full nodes are the ultimate arbiters of consensus=
+.=C2=A0<br><br>That&#39;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&#39;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&#39;t a dire threat is that there&#39;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>&gt;=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&#39;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>&gt;=C2=A0</span><span style=3D"font-size:1=
+2.8px">And it&#39;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&#3=
+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&#39;t nod=
+es voting - that&#39;s money voting.<br><br>Bitcoin is structured such that=
+ nodes have no votes because nodes cannot be trusted.=C2=A0 They don&#39;t =
+inherently represent individuals, they don&#39;t inherently represent value=
+, and they don&#39;t commit work that is played against eachother to achiev=
+e a game theory equilibrium.=C2=A0 That&#39;s miners.</span><div><span styl=
+e=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8p=
+x">&gt;=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&#39;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&#39;s don&#39;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&#39;=
+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>&gt;=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&#39;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&#39;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&#39;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&#39;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&#39;m open to being prove=
+n wrong.<br><br>&gt;=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&#3=
+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">&gt;=C2=A0</span><span style=
+=3D"font-size:12.8px">1GB I think is really the limit you&#39;d want to hav=
+e before you&#39;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&#39;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&#39;=
+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>&gt;=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&#39;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&#39;t rise at all due to blockspace competition (i.e., they offset only =
+the minimum required for miners to economically protect Bitcoin), they&#39;=
+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&#39;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>&gt;=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&#39;t mean to be rude here,=
+ but this kind of thinking is very poor logic when applied to anyone who is=
+n&#39;t already a libertarian Bitcoin supporter.=C2=A0 By anyone outside th=
+e Bitcoin world&#39;s estimation, Bitcoin is an extremely high risk, unreli=
+able store of value.=C2=A0 We like to compare it to &quot;digital gold&quot=
+; 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&#39;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&#39;t store your $10k+ in bitcoin, you&#39;ll store=
+ in $altcoin.=C2=A0 The market doesn&#39;t really care who wins.<br><br>&gt=
+;=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&#39;s nothing, we&#39;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">&lt;<a href=3D"mailto:bitcoin-dev@li=
+sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
+n.org</a>&gt;</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"">&gt; <span class=3D"m_5779025606995714197gmail-im">&gt=
+;=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">&gt; 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&#39;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&#39;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>&gt; <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&#39;s going to cost about $50 no matter what drive I pick, becaus=
+e that&#39;s just how much you have to spend to get a drive. The fact that =
+I get an extra 900 GB that I&#39;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>&gt; I don&#39;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&#39;m open to quanti=
+fying=20
+any of those if there&#39;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&#39;t have all of their p=
+rograms open at the same time. 1GB I think is really the limit you&#39;d wa=
+nt to have before you&#39;d start seeing users choose not to run nodes simp=
+ly because they&#39;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&#39;t even going to notice. Same fo=
+r electricity. They aren&#39;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>&gt; <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&#39;s crypto-currency marke=
+t
+ share.=C2=A0 Even if you are right, that&#39;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>&gt;=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&#39;t think I&#39;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--
+