Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)

[Lauda]

Nothing wrong for paying for coffee with Bitcoin or even the bitcoin network. But to whatever extent there is a choice between monetary sovereignty and direct blockchain small retail sales-- the latter can be replaced using a lot of different mechanisms (for coffee? even centralized ones, for godssakes!); and the former cannot...   I don't really think there is a fundamental mutual exclusion, but avoiding it will require being smarter, and not just cramming things in. Bitcoin: It's not a big truck.

Of more concern than "coffee" is transactions which have nothing to do with Bitcoin, transfer no Bitcoin value; and are just stuffing data into the bitcoin network because it's available; and some people have been going around selling the idea of ignoring the Bitcoin currency and saying that the system is just a big public database. This sort of stuff is out of scope for the Bitcoin system and endangers it survival when the cost of carting around a zillion 'stock transfer' zero value txouts overwhelms the public's interest in Bitcoin. ... and they've been a major driver for calls to remove Bitcoin's resource controls. I think totally separate assets need to have their own networks and fates, or otherwise one becomes an externalized cost on the other and can act as dead weight that removes the viability of the combined system.

I understand your points entirely. However, even if we make Bitcoin a system that is going to be used for very small everyday purchases like coffee, those don't necessarily have to be on the main chain. You don't need the strongest network in the world to secure your $1 purchase. This is one of the things that supporters of XT, BIP101, no limit/etc. have sometimes tried to use as a argument (not being able to buy coffee with small blocksize). I'm also aware of the concern of storing huge amounts of data on the blockchain which was not designed for that purpose and is very inefficient when it comes to that. How about something a few gigabytes in size? Wouldn't really work out in a efficient way.
To keep it short, someone of your expertise shouldn't waste too much time in this thread. People have been coming and going with very strong arguments, but the "opposing" side doesn't budge. Their way is the right way, or none is (not always, but often).

[sgbett]

Also for the record... three nodes... ~80 connections on each

[da2ce7]

BIP101 and the other block size proposals do nothing to actually scale the Bitcoin infrastructure, the only talk about changing the specification for Bitcoin infrastructure.

Of-course if you double the load-limit of a aircraft, it *may* still work, but if you double it again, it will probably fail in a spectacular manner.

Gavinista: I demand you immediately double the load-limit by doubling the airplane's wingspan.  No, you can't do a feasibility test in a wind tunnel first, Because Censorship!  Do it now or we hijack this bitch.

No, I don't think that you have got the analogy correct.

The BIP101 / XT crew are proposing to change the 'Technical Specification' of the aircraft. This is a document that describes under what conditions the aircraft is safe to operate, including load-limits.

Changing the 'Technical Specification' doesn't magically change what the aircraft is physically capable doing, it only changes how people will be inclined to use the aircraft.

BIP101 doesn't change Bitcoin's wingspan or any other physical quality that *may* make it safe to operate at twice the load. It only changes the document that describes how to use the aircraft safely.

This in itself isn't a bad thing; If the aircraft is overly conservatively specified, then updating the specification to reflect the actual capabilities of the aircraft is a prudent thing to do. - You want to of course maximize the utility of your aircraft.

However with BIP101, they are proposing to adjust the aircraft specification without even much looking at testing a model aircraft under such loads in a air tunnel, much less making a full-sized copy for rigorous test flights.

They are acting in complete disregard with established engineering concepts such as engineering safety factors, or conservative design specifications. - From a engineering point of view, those who propose BIP101 (or any other scaling proposal), without first showing scientific evidence and reasoning that such a proposal will be within the physical capabilities of the network, imho, are looking much like chumps.

Of course when an aircraft crashes, it costs hundreds of lives. - Bitcoin, only billions of dollars.

[hdbuck]

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.

Have faith in development or whatever, just let the developers work on proper scaling solutions.

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.

Big picture: "I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010

And it is exclusive from being highjacked with broken democracy social brigading.

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.

No, full blocks are meant to be in bitcoin.

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.

The reality of "open" software development is that anybody is free to contribute, but it does not imply it will be implemented by the network's participants.

Still, bitcoin unity relies on a consensus, not some various branding for all the braindeads spectrum a la cocacola zero, light and cherry.

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.

Supporting bigger blocks just for bigger blocks is childish and stands no ground in the technical debate.

I am supporting scaling solutions that do not hamper the decentralization and hence the security of bitcoin's network.
I am supporting bitcoin as an immuable force from which a healthy monetary system will emerge.

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.

Unbelievable, talking stuff like "belief" "could" "believe" "things" all the way down to such pseudo conclusion.

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

There is no point bending bitcoin's rules just to fit couple USG payment processors and broken fiat intermediaries.

To hell with the corporate leeches.

[gmaxwell]

And yet this information is ruthlessly attacked whenever it is pointed out-- I am routinely called a "bitcoin bear" even though I have a significant portion of my net worth tied up in it, simply for beveling in Bitcoin enough to be frank about the problems and limitations in it. Many people less convinced about Bitcoin's power and value than I and much more interested in the short term pump are unwilling to tolerate any discussion of challenges; and this creates a poisonous atmosphere which undermines the system's ability to heal and improve.

https://www.reddit.com/r/Bitcoin/comments/3uz0im/eli5_if_large_blocks_hurt_miners_with_slow/cxj3k01?context=3

[hdbuck]

And yet this information is ruthlessly attacked whenever it is pointed out-- I am routinely called a "bitcoin bear" even though I have a significant portion of my net worth tied up in it, simply for beveling in Bitcoin enough to be frank about the problems and limitations in it. Many people less convinced about Bitcoin's power and value than I and much more interested in the short term pump are unwilling to tolerate any discussion of challenges; and this creates a poisonous atmosphere which undermines the system's ability to heal and improve.

https://www.reddit.com/r/Bitcoin/comments/3uz0im/eli5_if_large_blocks_hurt_miners_with_slow/cxj3k01?context=3

Heh, seems gavin cant help but making a joke out of himself.

For the records:

Gmax: 24 commits last month  https://github.com/gmaxwell
Gavin: 0 commits last month  https://github.com/gavinandresen

Keep the faith Gmax.

[tl121]

And today we are left at a point where the bandwidth consumption of an ordinary Bitcoin node just barely fits within the 350GB/mo transfer cap of a high end, "best available in most of the US" broadband service. We cannot know to what degree the load increase was causative, but none of the metrics had positive outcomes; and this is a reason to proceed only with the greatest care and consideration. Especially against a backdrop where Bitcoin's fundamental utility as a money are being attacked by efforts to regulate people's ability to transact and to blacklist coins; efforts that critically depend on the existence of centralized choke-points which scale beyond the system's scalability necessarily creates.

The problem isn't the block data, which at the present 1 MB limit uses less than 3 percent of a 350 MB/month ISP cap.  The problem is that Bitcoin Core does not provide the instrumentation and tools to allow node operators to manage their bandwidth utilization.  The developers could fix this situation if they were so inclined.   I interpret this situation to a question of priorities and/or lack of network performance expertise on the part of Bitcoin Core developers.

[sgbett]

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.

Have faith in development or whatever, just let the developers work on proper scaling solutions.

opinion stated as fact

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.

Big picture: "I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010

And it is exclusive from being highjacked with broken democracy social brigading.

opinion stated as fact

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.

No, full blocks are meant to be in bitcoin.

opinion stated as fact

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.

The reality of "open" software development is that anybody is free to contribute, but it does not imply it will be implemented by the network's participants.

Still, bitcoin unity relies on a consensus, not some various branding for all the braindeads spectrum a la cocacola zero, light and cherry.

opinion stated as fact

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.

Supporting bigger blocks just for bigger blocks is childish and stands no ground in the technical debate.

opinion stated as fact

I am supporting scaling solutions that do not hamper the decentralization and hence the security of bitcoin's network.

opinion stated as fact

I am supporting bitcoin as an immuable force from which a healthy monetary system will emerge.

opinion stated as fact

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.

Unbelievable, talking stuff like "belief" "could" "believe" "things" all the way down to such pseudo conclusion.

I have opinions I do not state them as facts.

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

There is no point bending bitcoin's rules just to fit couple USG payment processors and broken fiat intermediaries.

opinion stated as fact

To hell with the corporate leeches.

probably opinion stated as fact, but its hard to tell

I think this is a common theme, and its not just you or your 'side'. There are plenty of big blockers that keep posting stuff that makes me cringe its just that they aren't rebutting my posts so there's no real reason to call them out.

Now I am not saying I am perfect, but I certainly try to make sure that I recognise what is my opinion and what are facts. I think if more people did this then the conversation could be much more productive.

My statement about XT being the only solution wasn't a conclusion, it was just one amongst several points. When you say things like "Supporting bigger blocks just for bigger blocks..." it implies that you have either not understood, or ignored what I wrote. I am in favour of big blocks for all of the reasons that I stated, and not just for their own sakes. I am troubled because the only option I have to 'support' big blocks is to run XT. They are related but independent points.

If you want a 'conclusion' then you would be better focusing on this comment: "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."

This comment is supposed to illustrate how software itself iterates, rather than to speak of the "open source" process. When a feature is developed algorithms are created. Those algorithms can sometimes trigger development - either the optimisation of existing algorithms, the refactoring of related code to take advantage of those new algorithms, or inspire different features based on the new algorithms. This is not an exhaustive list, but it illustrates the point I think. That sometimes it is not possible to see what will several steps ahead until some of the previous steps are implemented. To further clarify I am not saying that is the entirety of the development process, but it is one facet.

The conclusions would be that I think bigger blocks allow for more time to to continue developing scaling solutions without compromising the viability of bitcoin in terms of transaction throughput. That I think that this will not lead to dangerous levels of centralisation overnight (I agree it may not be sustainable - but conversely nobody can actually say that it is not) by making it prohibitively expensive to run a node. I think that there is not any need to attempt to artificially create a fee market when we are still in the position of coinbase being a huge revenue stream. I think that it is preferable to let a fee market develop organically.

However much you try and state that all of these opinions are wrong, you cannot categorically state that your counter opinions are any more factual. However strongly you might believe in them.

Hal Finney had an opinion, and you posted it. He could be right. Satoshi had an opinion too - its in my sig, maybe he is right. gmaxwell posted about how he though 'coffee on chain' was far less of a problem than 'nothing on chain' - I'd agree. Using the blockchain for non bitcoin transfer seems much further away from "what is bitcoin" than actually recording bitcoin transfer.

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

[MarketNeutral]

BIP101 and the other block size proposals do nothing to actually scale the Bitcoin infrastructure, the only talk about changing the specification for Bitcoin infrastructure.

Of-course if you double the load-limit of a aircraft, it *may* still work, but if you double it again, it will probably fail in a spectacular manner.

Gavinista: I demand you immediately double the load-limit by doubling the airplane's wingspan.  No, you can't do a feasibility test in a wind tunnel first, Because Censorship!  Do it now or we hijack this bitch.

No, I don't think that you have got the analogy correct.

The BIP101 / XT crew are proposing to change the 'Technical Specification' of the aircraft. This is a document that describes under what conditions the aircraft is safe to operate, including load-limits.

Changing the 'Technical Specification' doesn't magically change what the aircraft is physically capable doing, it only changes how people will be inclined to use the aircraft.

BIP101 doesn't change Bitcoin's wingspan or any other physical quality that *may* make it safe to operate at twice the load. It only changes the document that describes how to use the aircraft safely.

This in itself isn't a bad thing; If the aircraft is overly conservatively specified, then updating the specification to reflect the actual capabilities of the aircraft is a prudent thing to do. - You want to of course maximize the utility of your aircraft.

However with BIP101, they are proposing to adjust the aircraft specification without even much looking at testing a model aircraft under such loads in a air tunnel, much less making a full-sized copy for rigorous test flights.

They are acting in complete disregard with established engineering concepts such as engineering safety factors, or conservative design specifications. - From a engineering point of view, those who propose BIP101 (or any other scaling proposal), without first showing scientific evidence and reasoning that such a proposal will be within the physical capabilities of the network, imho, are looking much like chumps.

Of course when an aircraft crashes, it costs hundreds of lives. - Bitcoin, only billions of dollars.

Well put!

Satoshi is kind of analogous to the Wright Brothers, but these BIP101 clowns foolishly think they're bringing bitcoin into the jet age---but without the highly rigorous testing and design standards such a feat requires. BIP101 seems more like the infamous Spruce Goose to me.

[brg444]

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

Maybe you're not looking hard enough?

https://www.reddit.com/r/Bitcoin/comments/3uzwgs/scaling_bitcoin_2_in_just_5_days/

You're fooling yourself if you expect productive development to be held "on a forum such as this"

[tvbcof]

...
Satoshi is kind of analogous to the Wright Brothers, but these BIP101 clowns foolishly think they're bringing bitcoin into the jet age---but without the highly rigorous testing and design standards such a feat requires. BIP101 seems more like the infamous Spruce Goose to me.

The various exponential bloat strategies are sort of like 'bringing Bitcoin into the jet age' in the same way as the Darwin Awards guy who strapped a surplus JATO unit onto the top of his car.  In this case it's kind of like Mike Hearn had the idea but Gavin was to pilot the thing.

https://www.youtube.com/watch?v=0g9ssQSV6UA

[Carlton Banks]

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

Maybe you're not looking hard enough?

https://www.reddit.com/r/Bitcoin/comments/3uzwgs/scaling_bitcoin_2_in_just_5_days/

You're fooling yourself if you expect productive development to be held "on a forum such as this"

I notice alot of people using this forum as a platform to berate it. I also notice that alot of people are using this forum as a platform to advertise alternative forums.

Kind of an inconsistency between what these two groups are saying and what they're doing: Why do they keep coming back here if bitcointalk.org is held in such contempt?

[ArticMine]

And today we are left at a point where the bandwidth consumption of an ordinary Bitcoin node just barely fits within the 350GB/mo transfer cap of a high end, "best available in most of the US" broadband service. We cannot know to what degree the load increase was causative, but none of the metrics had positive outcomes; and this is a reason to proceed only with the greatest care and consideration. Especially against a backdrop where Bitcoin's fundamental utility as a money are being attacked by efforts to regulate people's ability to transact and to blacklist coins; efforts that critically depend on the existence of centralized choke-points which scale beyond the system's scalability necessarily creates.

The problem isn't the block data, which at the present 1 MB limit uses less than 3 percent of a 350 MB/month ISP cap.  The problem is that Bitcoin Core does not provide the instrumentation and tools to allow node operators to manage their bandwidth utilization.  The developers could fix this situation if they were so inclined.   I interpret this situation to a question of priorities and/or lack of network performance expertise on the part of Bitcoin Core developers.

This is a valid point and for once in this debate can lead to a constructive suggestion. If the choice is between contributing 350GB  for a full node and closing the port effectively contributing nothing and one has a 300 GB ISP cap then closing the port becomes the only option, even though the node could very easily contribute say 150 GB. There is a very disturbing all or nothing approach to this debate that leads to a choice between two bad options at both extremes.

[hdbuck]

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

Maybe you're not looking hard enough?

https://www.reddit.com/r/Bitcoin/comments/3uzwgs/scaling_bitcoin_2_in_just_5_days/

You're fooling yourself if you expect productive development to be held "on a forum such as this"

I notice alot of people using this forum as a platform to berate it. I also notice that alot of people are using this forum as a platform to advertise alternative forums.

Kind of an inconsistency between what these two groups are saying and what they're doing: Why do they keep coming back here if bitcointalk.org is held in such contempt?

Meh, if only they would stick with their VERified Kingdom. There surely must be as much freedom as idiocy there.

Starting to be a bit bored with the rhetoric manoeuvres.

Clearly the network has consensually rejected XT and BIP101.

At this point, I wonder what is the percentage of shills vs idiots amongst these forkers. (oh and yes that's an opinion, and a fact)

[sgbett]

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

Maybe you're not looking hard enough?

https://www.reddit.com/r/Bitcoin/comments/3uzwgs/scaling_bitcoin_2_in_just_5_days/

You're fooling yourself if you expect productive development to be held "on a forum such as this"

I'm going to clarify what I posted because I don't really understand why you have responded the way you have.

"petulant children arguing on a forum such as this" refers to the people on this forum that argue like petulant children

"but, if the developers are not" is a clause, which is prefixed by the statement "We don't know," which speaks to the nature of truth - such that unless you are one of the developers then you can't really know for sure however I included a subclass in parenthesis (and I believe this to be the case) to indicate that whilst I may not know I believe it to be the case (that "the developers are not").

You can re-arrange this sentence thusly "I believe the developers are not petulant children arguing on a forum such as this. Though, it is not possible for me to know that is a fact." however one can never really know". The reason I didn't write it in this order is because the words at the beginning of the sentence (comment on nature of truth) are less important and it is in the readers nature to focus on the later part of complex clause than the earlier part. This is why the last part of the sentence is drawing attention to the fact that people on this forum argue like petulant children. This is a contrast to to what the developers are (hopefully) doing. The very last part of that first sentence was the most important part though ", then its likely that their discussion will revolve around finding the common ground in between opposing opinions."

That's the bit i really wanted to stress, which is why its at the end.

Your response implies that you thought I said the opposite. Is that intentional, or just a genuine mistake?

[brg444]

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

Maybe you're not looking hard enough?

https://www.reddit.com/r/Bitcoin/comments/3uzwgs/scaling_bitcoin_2_in_just_5_days/

You're fooling yourself if you expect productive development to be held "on a forum such as this"

I notice alot of people using this forum as a platform to berate it. I also notice that alot of people are using this forum as a platform to advertise alternative forums.

Kind of an inconsistency between what these two groups are saying and what they're doing: Why do they keep coming back here if bitcointalk.org is held in such contempt?

Meh, if only they would stick with their VERified Kingdom. There surely must be as much freedom as idiocy there.

As ICEBREAkER aptly predicted let's just say they are having their their own freedom of speech problems 

https://www.reddit.com/r/bitcoinxt/comments/3uyyfx/i_didnt_think_this_day_would_come_but_ive_been/

[tl121]

This is a valid point and for once in this debate can lead to a constructive suggestion. If the choice is between contributing 350GB  for a full node and closing the port effectively contributing nothing and one has a 300 GB ISP cap then closing the port becomes the only option, even though the node could very easily contribute say 150 GB. There is a very disturbing all or nothing approach to this debate that leads to a choice between two bad options at both extremes.

When I was running a node with an open port I managed to keep the bandwidth down by various means, such as limiting the number of connections and implementing bandwidth caps on my upload bandwidth.  I tried to regulate things so that I was uploading about 1.5 x the amount I was downloading. I believe the most I ever used was about 100 GB/month combined upload and download.  (I ceased running an open port following two massive DDoS attacks which took down my ISP.)

From a little watching of my connection activity, I observed that a lot of the upload bandwidth was loading older blocks.  A limit on bandwidth provided for uploading older blocks would certainly help.  With some creative effort it might be possible to devise a scheme whereby full nodes could recoup some of their operating costs by charging leechers for services rendered.

[hdbuck]

We don't know, but (and I believe this to be the case) if the developers are not petulant children arguing on a forum such as this, then its likely that their discussion will revolve around finding the common ground in between opposing opinions. That would be a more interesting discussion to be having but all I see every day are polarised opinions (presented as fact). Exaggeration by both camps, hostility, refusal to move from entrenched positions and mischarecterisation of others views.

Maybe you're not looking hard enough?

https://www.reddit.com/r/Bitcoin/comments/3uzwgs/scaling_bitcoin_2_in_just_5_days/

You're fooling yourself if you expect productive development to be held "on a forum such as this"

I notice alot of people using this forum as a platform to berate it. I also notice that alot of people are using this forum as a platform to advertise alternative forums.

Kind of an inconsistency between what these two groups are saying and what they're doing: Why do they keep coming back here if bitcointalk.org is held in such contempt?

Meh, if only they would stick with their VERified Kingdom. There surely must be as much freedom as idiocy there.

As ICEBREAkER aptly predicted let's just say they are having their their own freedom of speech problems  

https://www.reddit.com/r/bitcoinxt/comments/3uyyfx/i_didnt_think_this_day_would_come_but_ive_been/

SPLITTER!!1

[VeritasSapere]

And today we are left at a point where the bandwidth consumption of an ordinary Bitcoin node just barely fits within the 350GB/mo transfer cap of a high end, "best available in most of the US" broadband service. We cannot know to what degree the load increase was causative, but none of the metrics had positive outcomes; and this is a reason to proceed only with the greatest care and consideration. Especially against a backdrop where Bitcoin's fundamental utility as a money are being attacked by efforts to regulate people's ability to transact and to blacklist coins; efforts that critically depend on the existence of centralized choke-points which scale beyond the system's scalability necessarily creates.

The problem isn't the block data, which at the present 1 MB limit uses less than 3 percent of a 350 MB/month ISP cap.  The problem is that Bitcoin Core does not provide the instrumentation and tools to allow node operators to manage their bandwidth utilization.  The developers could fix this situation if they were so inclined.   I interpret this situation to a question of priorities and/or lack of network performance expertise on the part of Bitcoin Core developers.

This is a valid point and for once in this debate can lead to a constructive suggestion. If the choice is between contributing 350GB  for a full node and closing the port effectively contributing nothing and one has a 300 GB ISP cap then closing the port becomes the only option, even though the node could very easily contribute say 150 GB. There is a very disturbing all or nothing approach to this debate that leads to a choice between two bad options at both extremes.

Might be worth pointing out here that the later version of XT does have a bandwidth throttling option, which I thought was a nice feature for people that do have data caps.

[Carlton Banks]

This is a valid point and for once in this debate can lead to a constructive suggestion. If the choice is between contributing 350GB  for a full node and closing the port effectively contributing nothing and one has a 300 GB ISP cap then closing the port becomes the only option, even though the node could very easily contribute say 150 GB. There is a very disturbing all or nothing approach to this debate that leads to a choice between two bad options at both extremes.

When I was running a node with an open port I managed to keep the bandwidth down by various means, such as limiting the number of connections and implementing bandwidth caps on my upload bandwidth.  I tried to regulate things so that I was uploading about 1.5 x the amount I was downloading. I believe the most I ever used was about 100 GB/month combined upload and download.  (I ceased running an open port following two massive DDoS attacks which took down my ISP.)

From a little watching of my connection activity, I observed that a lot of the upload bandwidth was loading older blocks.  A limit on bandwidth provided for uploading older blocks would certainly help.  With some creative effort it might be possible to devise a scheme whereby full nodes could recoup some of their operating costs by charging leechers for services rendered.

There was a pull request in the Bitcoin github to add -dailyuploadlimit in MB as a command line parameter, but I couldn't find it to see if it was merged into the main branch or not. It would mean you could set a 24 hour limit on the amount of historical block data (i.e. anything not the most recent 288 blocks) that other nodes could request.

Not sure what happened with that, looks like it didn't make it into 0.12, but perhaps I'm not looking hard enough. Or maybe there was a good reason not to include it (apparently network message anti-spamming measure did make it into 0.12)