Quote from: gmaxwell on December 01, 2015, 03:23:27 AM

Quote from: marcus_of_augustus on December 01, 2015, 01:34:41 AM

Wrong, wrong and more wrong.
The 1MB limit was put in place in 2010, not 2008. Actual bitcoin network upload speed (the real bottleneck) measurements show upload bandwidth for nodes at edge of network is growing at closer to 17-25%. (This disregards data caps for total bandwidth available also).

Bitcoin also had a 250kb limit at the time, implemented as a soft-rule by miners rather than a hard protocol rule. If you take the current system with a 2010 client (and much less a circa 2010 computer) it will likely not keep up with the network (if you try, let me know in a month when you complete the initial block download...

). The limits then were already set in a forward looking manner and we have been scrambling to keep up with the network as it's grown into them.

Quote from: klondike_bar on December 01, 2015, 02:46:42 AM

get real. you can buy a 1TB harddrive for $50 today and store BIP101-enabled blockchain onto it for years to come. then pay $50 more for a 4TB drive to handle a few more years of growth. or are you still using the same computer you owned in 1999 with its 1.6GHz singlecore, 512MB ram, and 60GB HDD (all cutting edge)?

This is ignorant of the total costs of operating a reliable production grade system in a commercial environment... including the need to be nowhere near capacity at any time even when run on underspeced/io-starved/misconfigured mystery-meat hosting in order to make sure that nothing especially clever or difficult is required so that you can employ commonly available ham-sandwiches as devops.

This may not be as true for businesses that really consider Bitcoin to be central to their business-- but, as a bitcoin-seriousness proxy, how many non-mining Bitcoin companies do you know of that mine and participate in the network consensus? (I know of only one, ahem; and it seems like in not to long the same may apply for running full nodes)... Ultimately if the system is only usable in a way that preserves its political and security properties by those who are those who are the "most serious" (and politically motivated) then it will not be a success as a decentralized system. It's not good enough to be accessible to some, to achieve decentralization it has to be broadly accessible.

There are many factors standing in the way of that; including indifference and a lack of education but resource impacts absolutely play a part of it. You don't see people widely outsourcing their DHCP daemons, though they're incidental to their business. Why isn't a Bitcoin node as invisible as a DHCP server? Go show me a DHCP server that uses tens of gigs of storage, hundreds of gigs of transfer, gigabytes of ram, significant amounts of CPU, etc. and all these demands constantly growing.

One of the reasons I think that XT has been as much of a flop as it has, so quickly, is that many of the people persuaded by the eloquent rants of misleading simplicity went and actually ran a Bitcoin node; and encountered the same costs and annoyances that users have been complaining about heavily since the soft limits were cranked... and lost their conviction. I know this is true for some, but I wouldn't be surprised if it were a more general pattern.(I also suspect that many, though probably not all, the people complaining about DOS attacks weren't just seeing the ordinary load that every other node sees; including the "attack like" traffic from people trying to trace transaction origins-- even I thought someone was attacking Core nodes and changed to identify as XT and saw no difference in traffic)... plus the whole, "unlimited blocks are great, so long as someone else is paying the cost", which doesn't actually work...

For me this is the strongest argument for small blocks that I have read to date, and I agree with it. It is expensive to run a node. (I'd argue not prohibitively, but thats a matter of opinion).

Despite this I still think we need bigger blocks, and in taking this road I think that the pain Gregory described above would increase. I think this is growing pain though and although its undesirable I don't think its symptomatic of terminal illness.

I absolutely have faith that "development" has some big answers to this, and that protocol/software improvement will be the thing that addresses the challenges we currently face with infrastructure requirements.

Essentially I think we can have it all, and that those that frame the debate as being mutually exclusive are too married to their position to see the big picture.

Bandwidth requirements are a big concern. Full blocks are a big concern. Speculation as to the consequences of these things (an in particular using those hypothetical concerns) to justify why we must do X is not helpful.

We should do a bit of X,Y and Z. I think in doing these things iteratively, further opportunities will present themselves. Thats the reality of software development (at least in my experience). Sometimes you have to do a bit of suck it and see. It might not be optimal at that given point in time, but it can help drive development in a more optimal direction.

My biggest concern is that the only option I have to support bigger blocks is XT. I'd hate for everyone to jump to that because it was the only viable alternative.

To be clear, its the fact there is only one option that is the problem. In and of itself I don't think XT is necessarily a bad option, and I certainly don't subscribe to the belief that it would automatically result in all the bad things happening. Over time it could potentially facilitate those things, but I also believe that if that were the case then this can be addressed.

Yes, I have "faith". Without it what is the point in anything.