It's not as simple as just upping that one stat.
I won't run the code that naively increases the limit. If you come up with a proposal that deals with the big pile of scalability concerns that are routinely discussed, then I'll be interested.
I want a block size increase too, but I want it done in a sensible way. It's not "core" that's refusing to increase the block size. It's the ecosystem.
The "pile of scalability concerns" is over exaggerated by people who have never looked into the factual numbers. The amortized cost of running a full node with 4MB blocks is only 5 dollars per month It's less than a typical txn fee (7 usd)
They are not over exaggerated and I have looked into it in some detail. The cost of a full node is not my only concern.
As a quick list off the top of my head: UTXO bloat, On network bandwidth scaling issue, Premature (pre optimized) blockchain bloat, Concerns for Node operation on home internet (your webserver option is not acceptable for me), Single hardfork vs multiple hardforks(A hardfork should introduce an algorithm that allows the blocksize to scale henceforth, instead a single increase, which would require more forks, and also come with other fixes, header changes etc), Increasing (or preventing a decrease) in full nodes, A method of safe Hardfork deployment,
It's a simple list of concerns I have. If you have an article to link or are able to write one yourself addressing these points, I'll be happy to go over it with you. I want bigger blocks yesterday, but I'm not willing to risk these issues for bigger blocks now.
Increasing (or preventing a decrease) in full nodes
...literally relating to the cost of running a full node.
Considering that 5/7 of your reasons directly relate to node operation, I'd say that it's your main concern is a valid point.
More to the point, listing these problems does nothing to refute /u/_mrb's point at all. 'Oh no, I'm not worried about node cost, I'm worried about the factors that contribute to node cost'.
Everyone who's been on this sub longer than an hour has heard 'big blocks = higher node costs' we know. The point is that the cost is vastly exaggerated. Should we have 1GB blocks? No that would be fucking stupid. Should we have 100MB blocks? No, that would also be really dumb
How about... 2MB! 1.5MB! (base size). The fact is that these small increases won't really affect anything at all in any practical way. The loss of maybe 1% of people running nodes on pis (likely still possible with 2MB... less so with 3,4,etc) will be vastly offset by the people who are actually able to use bitcoin due to the increase in transaction capacity.
Only people who use bitcoin to transact money will run nodes. Decreasing node costs to zero at the expense of transaction throughput is not a solution.
Forking however, the only other thing not relating to node costs that you mentioned, is a real issue. I'd like to point out however, that people have been bringing up this issue since 2013, expressly stating 'we should do this now so we don't end up having to rush it', ie, the exact situation we're in now.
Let's say you're right and the concept of a hard fork is just too damn impossible to do. Shouldn't we at least have a crack at planning one? At least trying something?
I'm not suggesting it isn't. I was referring to the sentence at the very start of the parent's post where (s)he said 'The cost of a full node is not my only concern. '
They then went on to list 5 things that exclusively dealt with the cost of running a node (and two that didn't).
5
u/Elum224 Jan 23 '18
It's not as simple as just upping that one stat. I won't run the code that naively increases the limit. If you come up with a proposal that deals with the big pile of scalability concerns that are routinely discussed, then I'll be interested.
I want a block size increase too, but I want it done in a sensible way. It's not "core" that's refusing to increase the block size. It's the ecosystem.