From: Jared Lee Richardson <jaredr26@gmail.com>
To: David Vorick <david.vorick@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Date: Wed, 29 Mar 2017 15:08:33 -0700 [thread overview]
Message-ID: <CAD1TkXvd4yLHZDAdMi78WwJ_siO1Vt7=DgYiBmP45ffVveuHBg@mail.gmail.com> (raw)
In-Reply-To: <CAFVRnyq9Qgw88RZqenjQTDZHEWeuNCdh12Dq7wCGZdu9ZuEN9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 15690 bytes --]
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 18662 bytes --]
next prev parent reply other threads:[~2017-03-29 22:08 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 19:33 [bitcoin-dev] Hard fork proposal from last week's meeting Daniele Pinna
2017-03-29 20:28 ` Peter R
2017-03-29 22:17 ` Jared Lee Richardson
2017-03-29 20:28 ` David Vorick
2017-03-29 22:08 ` Jared Lee Richardson [this message]
2017-03-30 7:11 ` Luv Khemani
2017-03-30 17:16 ` Jared Lee Richardson
2017-03-31 4:21 ` Luv Khemani
2017-03-31 5:28 ` Jared Lee Richardson
2017-03-31 8:19 ` Luv Khemani
2017-03-31 15:59 ` Jared Lee Richardson
2017-03-31 16:14 ` David Vorick
2017-03-31 16:46 ` Jared Lee Richardson
2017-03-31 18:23 ` David Vorick
2017-03-31 18:58 ` Eric Voskuil
2017-04-01 6:15 ` Jared Lee Richardson
-- strict thread matches above, loose matches on Subject: below --
2017-03-31 21:23 Rodney Morris
2017-03-31 23:13 ` Eric Voskuil
[not found] ` <CABerxhGeofH4iEonjB1xKOkHcEVJrR+D4QhHSw5cWYsjmW4JpQ@mail.gmail.com>
2017-04-01 1:41 ` Rodney Morris
2017-04-01 6:18 ` Jared Lee Richardson
2017-04-01 7:41 ` Eric Voskuil
[not found] ` <CAAt2M1_sHsCD_AX-vm-oy-4tY+dKoDAJhfVUc4tnoNBFn-a+Dg@mail.gmail.com>
[not found] ` <CAAt2M19Gt8PmcPUGUHKm2kpMskpN4soF6M-Rb46HazKMV2D9mg@mail.gmail.com>
2017-04-01 14:45 ` Natanael
[not found] ` <CAD1TkXusCe-O3CGQkXyRw_m3sXS9grGxMqkMk8dOvFNXeV5zGQ@mail.gmail.com>
2017-04-01 18:42 ` Jared Lee Richardson
[not found] ` <CAAt2M1_kuCBQWd9dis5UwJX8+XGVPjjiOA54aD74iS2L0cYcTQ@mail.gmail.com>
[not found] ` <CAAt2M19Nr2KdyRkM_arJ=LBnqDQQyLQ2QQ-UBC8=gFnemCdPMg@mail.gmail.com>
2017-04-01 13:26 ` Natanael
2017-03-29 19:50 Raystonn .
2017-03-30 10:34 ` Tom Zander
2017-03-30 11:19 ` David Vorick
2017-03-30 21:42 ` Jared Lee Richardson
2017-03-30 11:24 ` Aymeric Vitte
2017-03-28 19:56 Paul Iverson
2017-03-28 20:16 ` Pieter Wuille
2017-03-28 20:43 ` Tom Zander
2017-03-28 20:53 ` Alphonse Pace
2017-03-28 21:06 ` Luke Dashjr
2017-03-28 16:59 Wang Chun
2017-03-28 17:13 ` Matt Corallo
2017-03-29 8:45 ` Jared Lee Richardson
2017-03-28 17:23 ` Alphonse Pace
2017-03-28 17:31 ` Wang Chun
2017-03-28 17:33 ` Jeremy
2017-03-28 17:50 ` Douglas Roark
2017-03-28 17:33 ` Juan Garavaglia
2017-03-28 17:53 ` Alphonse Pace
2017-03-28 22:36 ` Juan Garavaglia
2017-03-29 2:59 ` Luv Khemani
2017-03-29 6:24 ` Emin Gün Sirer
2017-03-29 15:34 ` Johnson Lau
2017-04-01 16:15 ` Leandro Coutinho
2017-03-29 9:16 ` Jared Lee Richardson
2017-03-29 16:00 ` Aymeric Vitte
2017-03-28 17:34 ` Johnson Lau
2017-03-28 17:46 ` Luke Dashjr
2017-03-28 20:50 ` Tom Zander
2017-03-29 4:21 ` Johnson Lau
2017-03-28 20:48 ` Tom Zander
2017-03-29 6:32 ` Bram Cohen
2017-03-29 9:37 ` Jorge Timón
2017-03-29 19:07 ` Jared Lee Richardson
2017-04-02 19:02 ` Staf Verhaegen
2017-03-29 7:49 ` Martin Lízner
2017-03-29 15:57 ` David Vorick
2017-03-29 16:08 ` Aymeric Vitte
[not found] ` <CAFVRnyo1XGNbq_F8UfqqJWHCVH14iMCUMU-R5bOh+h3mtwSUJg@mail.gmail.com>
2017-03-29 16:18 ` David Vorick
2017-03-29 16:20 ` Andrew Johnson
2017-03-29 16:25 ` David Vorick
2017-03-29 16:41 ` Andrew Johnson
2017-03-29 17:14 ` Aymeric Vitte
2017-03-29 20:53 ` Jared Lee Richardson
2017-03-29 20:32 ` Jared Lee Richardson
2017-03-29 21:36 ` praxeology_guy
2017-03-29 22:33 ` Aymeric Vitte
2017-03-30 5:23 ` Ryan J Martin
2017-03-30 10:30 ` Tom Zander
2017-03-30 16:44 ` Jared Lee Richardson
2017-03-30 20:51 ` Jared Lee Richardson
2017-03-30 21:57 ` Tom Zander
[not found] ` <CAD1TkXvx=RKvjC8BUstwtQxUUQwG4eiU9XmF1wr=bU=xcVg5WQ@mail.gmail.com>
2017-03-30 10:13 ` Aymeric Vitte
2017-03-29 19:46 ` Jared Lee Richardson
2017-03-29 19:10 ` Jared Lee Richardson
2017-03-29 19:36 ` praxeology_guy
2017-04-02 19:12 ` Staf Verhaegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD1TkXvd4yLHZDAdMi78WwJ_siO1Vt7=DgYiBmP45ffVveuHBg@mail.gmail.com' \
--to=jaredr26@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=david.vorick@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox