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

[VeritasSapere]

Truth can stand on its own, people please use wisdom and reason, measure our arguments by thinking for yourself. Decide for yourself what you think would be the best path for Bitcoin. Do not be fooled by the constant ad hominem and sophistry. Inform your self and understand what the pros and cons are and do not forget that Bitcoin will reflect the will of its participants so think carefully of what you would like Bitcoin to become.

https://medium.com/faith-and-future/why-is-bitcoin-forking-d647312d22c1#.ybxg8kz61

Yes it does  

It sure does, which is why more then seventy percent of the miners now support bigger blocks.

Which pretty much means nothing until 100% of the nodes agree.  

That is impossible, 90%-100% consensus is impossible among large groups of people. Bitcoin was also never designed to be this way, Bitcoin can split with only 51% of the mining power. This is a good thing because it solves the age old problem of tyranny of the majority.

Watch it happen retard.

Still pretending a 51% miner attack is a legitimate fork of the network heh    oh well...

Do you understand what Bitcoin is? A peer-to-peer network? If you honestly believe the protocol is dictated by the mining power and not the actual peers then there's really no use wasting my time with you.

To be clear: no, Bitcoin cannot split with 51% of the hashing power.

I do think that Bitcoin is a peer to peer network, ultimately it is the peers/nodes/people that decide what Bitcoin becomes. Since it does reflect the will of its participants, if that will becomes split then so does Bitcoin. I do not think that a 51% split is always justified but it certainly is possible both theoretically and technically.

If the network is forked by the majority of the mining power and it is not supported by the people then that fork will not succeed because people will choose not to use it. This is why miners are incentivized not to go against the economic majority or the will of its participants, because it would be impossible to do so over the long run. This makes the interrelationship between the full nodes and the miners more complex. It is the miners that initiate the fork, while it is the nodes that ultimately decide which version will become the most dominant, this however is part of a process that does begin with the miners.

I use the term fifty one percent mainly for theoretical reasons since a split would be much more likely to occur when the majority introduces a fork which a smaller minority then refuses to follow. Which I think is within their right to do, in the same sense it is within the right of the majority to initiate a fork through the miner majority. It could be that over time the weaker chain could grow to become the more dominant chain again. If it proves itself to be better and more people choose to use that chain instead. In this way the market decides and people decide. This is the root of freedom behind cryptocurrency. However this does mean that the eccentricities and abstract nature of humanity will be reflected onto cryptocurrency as well with all of its flaws and beauty.

Whether a split will happen depends on the conditions. I think it is only justified when there are fundamental ideological disagreements that can not be resolved. I think it is highly unlikely that this will happen with this blocksize debate, however I am rather certain that we will see this happen in the future, most likely over entirely different issues. It is a radical concept but it does lie at the heart of the Bitcoin protocol and it will help secure the freedom presently inherent in Bitcoin. Even if the majority does not choose freedom, we will always still have the choice. This is the technological gift of financial freedom that cryptocurrency has given us.

[hdbuck]

Truth can stand on its own, people please use wisdom and reason, measure our arguments by thinking for yourself. Decide for yourself what you think would be the best path for Bitcoin. Do not be fooled by the constant ad hominem and sophistry. Inform your self and understand what the pros and cons are and do not forget that Bitcoin will reflect the will of its participants so think carefully of what you would like Bitcoin to become.

https://medium.com/faith-and-future/why-is-bitcoin-forking-d647312d22c1#.ybxg8kz61

Yes it does 

It sure does, which is why more then seventy percent of the miners now support bigger blocks.

Which pretty much means nothing until 100% of the nodes agree. 

That is impossible, 90%-100% consensus is impossible among large groups of people. Bitcoin was also never designed to be this way, Bitcoin can split with only 51% of the mining power. This is a good thing because it solves the age old problem of tyranny of the majority.

see? bitcoin is not a democracy...

[RoadTrain]

Its a bit strange that the small blockists are so opposed to BIP100 consider that BIP100 would allow the miners to decrease the blocksize if they determined this to be to their advantage.

Jeff Garzik, originator of BIP100, has himself stated it is unlikely (read:impossible) that BIP100 gets adopted so there's really no point debating it.

We are opposed to it because we understand the game theory dynamics of Bitcoin which quite obviously you don't  

Fortunately it is not up to the Core developers what proposal the economic majority will adopt. If Jeff Garzik does not implement BIP100 then other people can implement this so far hypothetical BIP100 instead. I would not be surprised if Core took to long to implement this, that the miners themselves might even release and support this implementation.

For the millionth time, the miners don't decide what code gets run, the nodes do.

Core doesn't bother with BIP100 as it is clear its hasn't gotten near consensus acceptance from relevant actors and so it should be considered dead.

Cores idea of developer consensus is laughable they just censor and ban anyone who does not agree with them and call that consensus. True Bitcoin consensus is superior, firstly reflected by proof of work and then by the full nodes.

While your idea that miners can fork the chain with 51% (they can do that with any percentage, actually) is technically correct, it's barely applicable in the real world.

Miners are among those entities losing the most in case of disruptions. They are incentivized to be as conservative as possible, which means that, when acting rationally, they will strive to get near-100% consensus on every important change. That's the reason they have rejected BIP101. That's the reason they are only passively voting for BIP100.

My expectation is that within the next 6-12 months there will be an acceptable schedule like 30% yearly increase for a couple years. This time limit will ensure that we're conservative enough so as not to cause any disruptions.

My personal preference would be keeping the limit as low as possible, even if it means 'Fidelity problem' persists. My anecdotal evidence tells that a couple days ago I had to stop running a full node. The amount of resources it comsumes has become unacceptable to me. The last straw was the power outage that resulted in a corrupted database. The reindexing takes ages, while you can't even comfortably watch Youtube. As the time goes, resources being consumed to do initial-sync only increase. And this is a guaranteed increase, unlike increases in hardware performance. I would personally want optimizations first, and then a limit bump, not the other way around.

[VeritasSapere]

Its a bit strange that the small blockists are so opposed to BIP100 consider that BIP100 would allow the miners to decrease the blocksize if they determined this to be to their advantage.

Jeff Garzik, originator of BIP100, has himself stated it is unlikely (read:impossible) that BIP100 gets adopted so there's really no point debating it.

We are opposed to it because we understand the game theory dynamics of Bitcoin which quite obviously you don't  

Fortunately it is not up to the Core developers what proposal the economic majority will adopt. If Jeff Garzik does not implement BIP100 then other people can implement this so far hypothetical BIP100 instead. I would not be surprised if Core took to long to implement this, that the miners themselves might even release and support this implementation.

For the millionth time, the miners don't decide what code gets run, the nodes do.

Core doesn't bother with BIP100 as it is clear its hasn't gotten near consensus acceptance from relevant actors and so it should be considered dead.

Cores idea of developer consensus is laughable they just censor and ban anyone who does not agree with them and call that consensus. True Bitcoin consensus is superior, firstly reflected by proof of work and then by the full nodes.

While your idea that miners can fork the chain with 51% (they can do that with any percentage, actually) is technically correct, it's barely applicable in the real world.

Miners are among those entities losing the most in case of disruptions. They are incentivized to be as conservative as possible, which means that, when acting rationally, they will strive to get near-100% consensus on every important change. That's the reason they have rejected BIP101. That's the reason they are only passively voting for BIP100.

My expectation is that within the next 6-12 months there will be an acceptable schedule like 30% yearly increase for a couple years. This time limit will ensure that we're conservative enough so as not to cause any disruptions.

My personal preference would be keeping the limit as low as possible, even if it means 'Fidelity problem' persists. My anecdotal evidence tells that a couple days ago I had to stop running a full node. The amount of resources it comsumes has become unacceptable to me. The last straw was the power outage that resulted in a corrupted database. The reindexing takes ages, while you can't even comfortably watch Youtube. As the time goes, resources being consumed to do initial-sync only increase. And this is a guaranteed increase, unlike increases in hardware performance. I would personally want optimizations first, and then a limit bump, not the other way around.

I agree that miners would not fork unless they thought they had a high degree of consensus, which is why it is highly unlikely in the real world that such a 51% fork would take place, I was just using this example to illustrate a point.

I disagree with the viability of near 100% consensus especially for contentious issues. I think that 70%-100% is sufficient, especially considering that a small minority would be able to enforce their beliefs onto Bitcoin purely by preventing any change.

I would actually support a thirty percent increase per year when implemented.

I would also personally prefer optimizations first, however I do think that if these optimizations are not completed before we need to increase the blocksize then the blocksize should just be increased anyway.

The primary scenario that I would like to avoid is transactions becoming unreliable and much more expensive, as long as that does not happen I would be happy with the situation. Which is why I can also agree to a yearly thirty percent increase. I am not prepared to "trust" Core to implement this however, there should be a limit to our patience. I am not prepared to wait for several years for instance, especially if that means that the scenario I described plays out. Since if that did happen then our "trust" was certainly misplaced and Bitcoin would suffer for it.

[muyuu]

It's not a matter of agreement, a lot of people have stopped running their nodes for these reasons and there is overwhelming evidence of this fact.

We are not conjecturing about whether they will stop or not, this already happens, I know many cases myself and they are all over the place in this forum and reddit.

Ask people who stopped running their nodes why the did they stop.

These are facts to deal with, not to agree or disagree.

I could say that there is overwhelming evidence to support what I am saying as well. Though that does not change your position does it. Stop pretending as if your position is the absolute truth based on factual evidence while saying that my position has absolutely no merit. Ridiculing my position to increase the blocksize as if I am some sort of mad man. When very reasonable and well informed people like Andreas Antonopoulos also support this position.


[...]

I can tell you that I have absolutely no problems running my full node and neither do the people around me. So my life and my experience and that of the people around me does serve as a counterfactual to what you are saying. Of course some people will not be able to run full nodes forever but we should not expect them to especially when the sacrifice that this would require would be to great. With sacrifice I am referring to limiting the amount of people that can use Bitcoin.

That means you are already compromising decentralisation. That you personally can run a node is irrelevant, the problem is that many people can no longer run one and you cannot prove this to be false because it isn't.

XT's solution is to further compromise the network by introducing throttling in a desperate attempt to pump their numbers: https://www.reddit.com/r/btc/comments/3q5r6b/we_added_bandwidthlimiting_in_xt_testers_wanted/cwc8vp8

[VeritasSapere]

It's not a matter of agreement, a lot of people have stopped running their nodes for these reasons and there is overwhelming evidence of this fact.

We are not conjecturing about whether they will stop or not, this already happens, I know many cases myself and they are all over the place in this forum and reddit.

Ask people who stopped running their nodes why the did they stop.

These are facts to deal with, not to agree or disagree.

I could say that there is overwhelming evidence to support what I am saying as well. Though that does not change your position does it. Stop pretending as if your position is the absolute truth based on factual evidence while saying that my position has absolutely no merit. Ridiculing my position to increase the blocksize as if I am some sort of mad man. When very reasonable and well informed people like Andreas Antonopoulos also support this position.


[...]

I can tell you that I have absolutely no problems running my full node and neither do the people around me. So my life and my experience and that of the people around me does serve as a counterfactual to what you are saying. Of course some people will not be able to run full nodes forever but we should not expect them to especially when the sacrifice that this would require would be to great. With sacrifice I am referring to limiting the amount of people that can use Bitcoin.

That means you are already compromising decentralisation. That you personally can run a node is irrelevant, the problem is that many people can no longer run one and you cannot prove this to be false because it isn't.

XT's solution is to further compromise the network by introducing throttling in a desperate attempt to pump their numbers: https://www.reddit.com/r/btc/comments/3q5r6b/we_added_bandwidthlimiting_in_xt_testers_wanted/cwc8vp8

It is ridiculous to maintain that everybody should be able to continue running a full node, surely there should be a lower bound to this requirement. For instance we should not downscale the network so that people with dial up connection can run full nodes. Of course there will always be people that will no longer be able to run full nodes and in the same sense there will always be new people running full nodes again.

In regards to the new feature just added to XT, I would think it is rather useful since surely it is better to throttle a full node as opposed to just shutting it down if you are in a location where there is limited bandwidth.

[Carlton Banks]

It is ridiculous to maintain that everybody should be able to continue running a full node, surely there should be a lower bound to this requirement.

And this reveals the dishonesty of your position (as ever).

It was only a few weeks ago you that and the rest of the XT cheerleaders were claiming that the BIP101 schedule was more than adequate to allow the majority of ordinary users to run full nodes.

Now, we see that you are subtly shifting your position towards the SPV-for-all end of the spectrum. If you wish to continue shouting about sophistry and conceited arguments, remember that you're already shouting as such all too frequently.

[tl121]

My personal preference would be keeping the limit as low as possible, even if it means 'Fidelity problem' persists. My anecdotal evidence tells that a couple days ago I had to stop running a full node. The amount of resources it comsumes has become unacceptable to me. The last straw was the power outage that resulted in a corrupted database. The reindexing takes ages, while you can't even comfortably watch Youtube. As the time goes, resources being consumed to do initial-sync only increase. And this is a guaranteed increase, unlike increases in hardware performance. I would personally want optimizations first, and then a limit bump, not the other way around.

Sorry you had a bitcoin database crash.  You have learned a basic lesson about running a bitcoin node.  A bitcoin node is a database server.  It is inappropriate to run a database server on a machine that is not dedicated to running a limited number of servers and has been configured to provide adequate performance for these uses.  In the case of data base machines where crash recovery is lengthy, this means it is inappropriate to run it on a machine that lacks reliable (e.g. battery backedup) power and stable software.  It is also inappropriate to run a server on a machine that is used to surf the web, or otherwise provide a huge attack surface to the network.  It is also inappropriate to run it if the operator doesn't know this, something that you have apparently learned. I learned this a while back pretty much the way you did. As a result I purchased, assembled and configured a dedicated computer to serve as my bitcoin node. This machine resides in my "home office data center".

Most people lack the knowledge and inclination to run their own servers in a reasonable "data center" environment. Until the arrival of SPV clients this was the only alternative for people wishing to use bitcoin. With SPV clients this is no longer necessary, and the truth is that most people would be ill advised to run a full bitcoin node even if they had unlimited network bandwidth and money to spend on a dedicated server.  They lack the necessary skills.

Even with a dedicated machine, unless one has excess network bandwidth one may observe degradation of activities on other computers (e.g. watching You-Tube videos) due to interference.  With suitable configuration of one's router it is possible to eliminate this interference by limiting the amount of bandwidth used by the bitcoin node.  However, doing this requires additional skills, namely knowledge of how to manage and tune computer networks.

Regardless of block size limit, it will be impractical or impossible for the majority of bitcoin users to run full nodes, unless bitcoin regresses to be a hobbyist and/or "science project" operation.

[Meuh6879]

It is ridiculous to maintain that everybody should be able to continue running a full node, surely there should be a lower bound to this requirement. For instance we should not downscale the network so that people with dial up connection can run full nodes.

well, that's the point where i don't agree.
Bitcoin, the network is build with node and ... personal node AT THE FIRST PLACE.

and like all P2P software, i want to restrict the usage of this programm ... with RAM used and BANDWITH used.

that's why i have choose the XT ... not really for the BIP101 ... but because developpers ask to immediat problem of personal USE of a full node.

i want a full node. 
i want it. 

but not installed on a data-server with monthly invoice ...

[muyuu]

In regards to the new feature just added to XT, I would think it is rather useful since surely it is better to throttle a full node as opposed to just shutting it down if you are in a location where there is limited bandwidth.

Actually no, this will just introduce latency in the network if a significant number of nodes did it (thankfully no danger of that happening just yet).

[RoadTrain]

My personal preference would be keeping the limit as low as possible, even if it means 'Fidelity problem' persists. My anecdotal evidence tells that a couple days ago I had to stop running a full node. The amount of resources it comsumes has become unacceptable to me. The last straw was the power outage that resulted in a corrupted database. The reindexing takes ages, while you can't even comfortably watch Youtube. As the time goes, resources being consumed to do initial-sync only increase. And this is a guaranteed increase, unlike increases in hardware performance. I would personally want optimizations first, and then a limit bump, not the other way around.

Sorry you had a bitcoin database crash.  You have learned a basic lesson about running a bitcoin node.  A bitcoin node is a database server.  It is inappropriate to run a database server on a machine that is not dedicated to running a limited number of servers and has been configured to provide adequate performance for these uses.  In the case of data base machines where crash recovery is lengthy, this means it is inappropriate to run it on a machine that lacks reliable (e.g. battery backedup) power and stable software.  It is also inappropriate to run a server on a machine that is used to surf the web, or otherwise provide a huge attack surface to the network.  It is also inappropriate to run it if the operator doesn't know this, something that you have apparently learned. I learned this a while back pretty much the way you did. As a result I purchased, assembled and configured a dedicated computer to serve as my bitcoin node. This machine resides in my "home office data center".

Most people lack the knowledge and inclination to run their own servers in a reasonable "data center" environment. Until the arrival of SPV clients this was the only alternative for people wishing to use bitcoin. With SPV clients this is no longer necessary, and the truth is that most people would be ill advised to run a full bitcoin node even if they had unlimited network bandwidth and money to spend on a dedicated server.  They lack the necessary skills.

Even with a dedicated machine, unless one has excess network bandwidth one may observe degradation of activities on other computers (e.g. watching You-Tube videos) due to interference.  With suitable configuration of one's router it is possible to eliminate this interference by limiting the amount of bandwidth used by the bitcoin node.  However, doing this requires additional skills, namely knowledge of how to manage and tune computer networks.

Regardless of block size limit, it will be impractical or impossible for the majority of bitcoin users to run full nodes, unless bitcoin regresses to be a hobbyist and/or "science project" operation.

Did you notice that it was anecdotal evidence? Don't take what I wrote literally. What I tried to show is not how it's bad, but how it's getting worse as time goes on and tx rates rise. Especially the initial-sync part.

And you have only proven my point. The cost of running a full node is increasing. The cost to possess monetary sovereignty is increasing. I'm concerned with that trend. That's it.

[hdbuck]

My personal preference would be keeping the limit as low as possible, even if it means 'Fidelity problem' persists. My anecdotal evidence tells that a couple days ago I had to stop running a full node. The amount of resources it comsumes has become unacceptable to me. The last straw was the power outage that resulted in a corrupted database. The reindexing takes ages, while you can't even comfortably watch Youtube. As the time goes, resources being consumed to do initial-sync only increase. And this is a guaranteed increase, unlike increases in hardware performance. I would personally want optimizations first, and then a limit bump, not the other way around.

Sorry you had a bitcoin database crash.  You have learned a basic lesson about running a bitcoin node.  A bitcoin node is a database server.  It is inappropriate to run a database server on a machine that is not dedicated to running a limited number of servers and has been configured to provide adequate performance for these uses.  In the case of data base machines where crash recovery is lengthy, this means it is inappropriate to run it on a machine that lacks reliable (e.g. battery backedup) power and stable software.  It is also inappropriate to run a server on a machine that is used to surf the web, or otherwise provide a huge attack surface to the network.  It is also inappropriate to run it if the operator doesn't know this, something that you have apparently learned. I learned this a while back pretty much the way you did. As a result I purchased, assembled and configured a dedicated computer to serve as my bitcoin node. This machine resides in my "home office data center".

Most people lack the knowledge and inclination to run their own servers in a reasonable "data center" environment. Until the arrival of SPV clients this was the only alternative for people wishing to use bitcoin. With SPV clients this is no longer necessary, and the truth is that most people would be ill advised to run a full bitcoin node even if they had unlimited network bandwidth and money to spend on a dedicated server.  They lack the necessary skills.

Even with a dedicated machine, unless one has excess network bandwidth one may observe degradation of activities on other computers (e.g. watching You-Tube videos) due to interference.  With suitable configuration of one's router it is possible to eliminate this interference by limiting the amount of bandwidth used by the bitcoin node.  However, doing this requires additional skills, namely knowledge of how to manage and tune computer networks.

Regardless of block size limit, it will be impractical or impossible for the majority of bitcoin users to run full nodes, unless bitcoin regresses to be a hobbyist and/or "science project" operation.

Did you notice that it was anecdotal evidence? Don't take what I wrote literally. What I tried to show is not how it's bad, but how it's getting worse as time goes on and tx rates rise. Especially the initial-sync part.

And you have only proven my point. The cost of running a full node is increasing. The cost to possess monetary sovereignty is increasing. I'm concerned with that trend. That's it.

trade offs & greed.

[VeritasSapere]

It is ridiculous to maintain that everybody should be able to continue running a full node, surely there should be a lower bound to this requirement.

And this reveals the dishonesty of your position (as ever).

It was only a few weeks ago you that and the rest of the XT cheerleaders were claiming that the BIP101 schedule was more than adequate to allow the majority of ordinary users to run full nodes.

Now, we see that you are subtly shifting your position towards the SPV-for-all end of the spectrum. If you wish to continue shouting about sophistry and conceited arguments, remember that you're already shouting as such all too frequently.

BIP101 does allow the majority of people in the developed world to continue running full nodes, some people will not be able to, I have never denied that. You are not the one to talk about sophistry attacking me the way that you are.

[VeritasSapere]

My personal preference would be keeping the limit as low as possible, even if it means 'Fidelity problem' persists. My anecdotal evidence tells that a couple days ago I had to stop running a full node. The amount of resources it comsumes has become unacceptable to me. The last straw was the power outage that resulted in a corrupted database. The reindexing takes ages, while you can't even comfortably watch Youtube. As the time goes, resources being consumed to do initial-sync only increase. And this is a guaranteed increase, unlike increases in hardware performance. I would personally want optimizations first, and then a limit bump, not the other way around.

Sorry you had a bitcoin database crash.  You have learned a basic lesson about running a bitcoin node.  A bitcoin node is a database server.  It is inappropriate to run a database server on a machine that is not dedicated to running a limited number of servers and has been configured to provide adequate performance for these uses.  In the case of data base machines where crash recovery is lengthy, this means it is inappropriate to run it on a machine that lacks reliable (e.g. battery backedup) power and stable software.  It is also inappropriate to run a server on a machine that is used to surf the web, or otherwise provide a huge attack surface to the network.  It is also inappropriate to run it if the operator doesn't know this, something that you have apparently learned. I learned this a while back pretty much the way you did. As a result I purchased, assembled and configured a dedicated computer to serve as my bitcoin node. This machine resides in my "home office data center".

Most people lack the knowledge and inclination to run their own servers in a reasonable "data center" environment. Until the arrival of SPV clients this was the only alternative for people wishing to use bitcoin. With SPV clients this is no longer necessary, and the truth is that most people would be ill advised to run a full bitcoin node even if they had unlimited network bandwidth and money to spend on a dedicated server.  They lack the necessary skills.

Even with a dedicated machine, unless one has excess network bandwidth one may observe degradation of activities on other computers (e.g. watching You-Tube videos) due to interference.  With suitable configuration of one's router it is possible to eliminate this interference by limiting the amount of bandwidth used by the bitcoin node.  However, doing this requires additional skills, namely knowledge of how to manage and tune computer networks.

Regardless of block size limit, it will be impractical or impossible for the majority of bitcoin users to run full nodes, unless bitcoin regresses to be a hobbyist and/or "science project" operation.

Did you notice that it was anecdotal evidence? Don't take what I wrote literally. What I tried to show is not how it's bad, but how it's getting worse as time goes on and tx rates rise. Especially the initial-sync part.

And you have only proven my point. The cost of running a full node is increasing. The cost to possess monetary sovereignty is increasing. I'm concerned with that trend. That's it.

I would like to point out that people do still have a high degree of monetary sovereignty when using SPV, many of the advantageous of Bitcoin over fiat are still present when using a SPV wallet. It might not be as good as using a full node however it certainly does allow for more inclusion into Bitcoin. SPV wallet also makes sense for a lot of people, not everyone has a desktop computer or is technically inclined after all.

Node centralization is a legitimate concern which is why I would favor either BIP100 or BIP103 when implemented. Just to side with caution and make consensus easier. I can agree with you on this point at least RoadTrain.

[brg444]

It is ridiculous to maintain that everybody should be able to continue running a full node, surely there should be a lower bound to this requirement.

And this reveals the dishonesty of your position (as ever).

It was only a few weeks ago you that and the rest of the XT cheerleaders were claiming that the BIP101 schedule was more than adequate to allow the majority of ordinary users to run full nodes.

Now, we see that you are subtly shifting your position towards the SPV-for-all end of the spectrum. If you wish to continue shouting about sophistry and conceited arguments, remember that you're already shouting as such all too frequently.

BIP101 does allow the majority of people in the developed world to continue running full nodes, some people will not be able to, I have never denied that. You are not the one to talk about sophistry attacking me the way that you are.

I disagree, I'm a very well off European with very cheap internet access and I personally don't think it is inconvenient nor expensive to run my node. Third-world problems are not my problems.

 

[VeritasSapere]

I disagree, I'm a very well off European with very cheap internet access and I personally don't think it is inconvenient nor expensive to run my node. Third-world problems are not my problems.

The highlighted quote was not made by me. Brg444 has unethically and falsely used my name in a quote which I am not responsible for, it was most likely written by him. To do this is wrong, it is fraud, libel and slander. I have requested that he ceases to falsely quote me yet he continues to do so.

[dooglus]

The highlighted quote was not made by me. Brg444 has unethically and falsely used my name in a quote which I am not responsible for, it was most likely written by him. To do this is wrong, it is fraud, libel and slander. I have requested that he ceases to falsely quote me yet he continues to do so.

The quote wasn't made by you, but it very accurately predicted things you were to say later.

The fact that you are lucky enough to be able to afford to run a full node has no bearing on the discussion. Lots of people are unable to run a full node already, and certainly wouldn't be able to keep up with XT's plan of doubling the blocksize limit every 2 years until it is 8192 times bigger than the current limit.

[brg444]

The highlighted quote was not made by me. Brg444 has unethically and falsely used my name in a quote which I am not responsible for, it was most likely written by him. To do this is wrong, it is fraud, libel and slander. I have requested that he ceases to falsely quote me yet he continues to do so.

The quote wasn't made by you, but it very accurately predicted things you were to say later.

The fact that you are lucky enough to be able to afford to run a full node has no bearing on the discussion. Lots of people are unable to run a full node already, and certainly wouldn't be able to keep up with XT's plan of doubling the blocksize limit every 2 years until it is 8192 times bigger than the current limit.

Bu..buut buttt the majority of the very privileged, global minority, of users in the developed world can run a node!! Screw the other guys, they don't need to run full nodes, they can just use SPV right, right !? I mean, if me & my friends can run a node from the comfort of our european metropolis that should be enough decentralization?

At least I think so... and if you don't agree well man it's just like.. your opinion, yaknow?

[MbccompanyX]

I disagree, I'm a very well off European with very cheap internet access and I personally don't think it is inconvenient nor expensive to run my node. Third-world problems are not my problems.

The highlighted quote was not made by me. Brg444 has unethically and falsely used my name in a quote which I am not responsible for, it was most likely written by him. To do this is wrong, it is fraud, libel and slander. I have requested that he ceases to falsely quote me yet he continues to do so.

dude stop playing the victim, i saw that post on the thread posted under your name, for once admit you just wrote something and anyway you know thay you are the only one posting more then the others?

[brg444]

I disagree, I'm a very well off European with very cheap internet access and I personally don't think it is inconvenient nor expensive to run my node. Third-world problems are not my problems.

The highlighted quote was not made by me. Brg444 has unethically and falsely used my name in a quote which I am not responsible for, it was most likely written by him. To do this is wrong, it is fraud, libel and slander. I have requested that he ceases to falsely quote me yet he continues to do so.

dude stop playing the victim, i saw that post on the thread posted under your name, for once admit you just wrote something and anyway you know thay you are the only one posting more then the others?

 

Let's not get carried away here.

It was indeed me who imagined these lines and stuck them under one of his posts' header so as to present what I thought would be his likely answer to a certain argument.

Of course subsequent posts from him proved my prescience and was the source of quite some lulz