First of all I never said that you should not distrust anyone. I said that you should never have to trust a developer of a Bitcoin client that is open source. I think that the DDOS protection feature within XT is innocent, however I do not even need to argue that point, because it does not matter what we think about it in terms of consensus. Since only the block size increase is fundamental to the protocol in terms of it causing a hard fork, It makes the other changes within XT optional. Since anyone can create their own client and make it behave in any way they would want as long as it is consistent with the fundamental rules of the protocol, the only fundamental rule that is changed within XT is the increase of the block size. You can turn off, any of the extra patches contained within Bitcoin XT inside of the client itself. There is even an alternative version of XT that does not include any of these other changes and only increases the block size. You could even run a patched version of Core that implements BIP101, which would then be compatible with XT after the fork if the miners reach consensus.
https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocksYeah, that's the standard answer. Assuming bitcoin is forked to BIP 101 and XT becomes mainstream -- unlikely, I know
-- what percentage of people do you think will use the standard XT client with standard settings? You, I and everyone reading this knows that the vast majority of users will not be compiling their own code. It's up to the community to make people aware of such controversial patches to prevent XT from becoming the norm in the first place (as unlikely as that is).
To be clear, you don't actually deny that a third party uploading a list of deprioritized IP addresses is a centralized, trust-adding feature, do you? But I assume it's okay, because the apocalypse will happen if BIP 101 isn't implemented yesterday....right?
What you are saying here is the equivalent of saying that people should not be trusted with the freedom of choice. To think that we should only have one "official" client because people are not capable of making the right choice for themselves is an extremely centralizing point of view.
That's not what I said at all. You're just setting up another straw man argument. People should have freedom to use whatever client they want. I'd love to see more competition in that sense, too. But it's our job as a community to root out bad implementations that encourage trust, and to discourage their use. That's our right and duty. You accusing me of having an "extremely centralizing point of view" for what amounts to critical thinking is laughable. What's happening here is continued use of populist arguments in response to legitimate criticism.
As a result of populist tactics, people overwhelmingly believe that
the one alternative presented is the only option. But there isn't only one alternative (the 1MB status quo) -- that's just a populist straw man argument, used to rile people up in support of their proposal.
Yes, I support increasing the block limit size limit and I think there are more sensible implementations than BIP 101 -- including those that haven't been presented yet. I'm just not willing to opt in favor of the first and only option for a hard fork when I think it could lead to disastrous problems down the road. No one has the technical foresight to predict all the problems that could occur when scaling bitcoin 8000x. It could be simply disastrous for network security, and it's so insulting that people think we have all contingencies covered, today, six years into the bitcoin project.
I think this debate is being rushed and people feel forced into the only option they see. That's a mistake. There is less urgency than people are making it out to be. We won't be maxing out the limit on average for another year. Even if we had a fee market temporarily, it really wouldn't be the end of the world. That's far preferable IMO to rushing a contentious fork -- there are many different stakeholders to consider.
Now that the stress test put the question at the forefront of issues facing the community, I hope to see more discussion, more skepticism of the idea that there are only two options (1MB status quo or 8GB endgame) -- there are endless potential solutions, including more gradual ones that allow us more time to deal with the issues that
will come with scaling over time. And you have the audacity to say that I therefore have an "extremely centralizing point of view?" Mischaracterization after mischaracterization. Straw man after straw man. Throw a buzz word in and you can't lose, right?
I can agree that there is an aspect of centralization with uploading IP addresses for this purpose, However this should not be considered as a trust adding feature as you claim it to be, since it is optional and rather innocent in practice.
I am glad that you can agree that it is centralizing. However, since it depends on third party trust, it is by definition a trust-adding feature. If you were the only person running a standard XT node, that would still be true.
I'm glad you bring up "practice." That's exactly the thing. This is about theory, and defining bitcoin as trustless. There is a decentralized solution before you which offers no less network security -- nodes can deprioritize IPs that are maliciously attacking them without any centralized list. I don't understand why this is a question at all.
Furthermore placing our trust in the Core development team is a far more dangerous form of centralization then compared to anything else that is within the Bitcoin XT client.
Distrusting XT or BIP 101 =/= trusting the Core development team. That's another blatant mischaracterization that keeps being throw around. Please keep the discussion honest.
You do realize that this feature was only added as a direct response to XT nodes being DDOS from TOR?
Yeah, someone posted the perfect retort to that:
Perhaps if attacks are predominantly coming from Malaysia, we should begin deprioritizing Malaysian IP ranges. There are geo-IP services that we can trust as a third party to compile lists of such suspicious IP ranges, too.
All that some of us ask is that people stop supporting unnecessary centralized solutions. Just admit that there are better ways to approach DDOS attacks.
Indeed, like simply having nodes deprioritize IPs that are actively attacking them. This is a simple, decentralized solution that requires no third party trust. Why aren't XT supporters at least lobbying Gavin Anderson and Mike Hearn to change this? Rather than arguing that it's "innocent?"
Since without this feature the full node would not be able to connect or function whatsoever.
Come again?
This feature is also disabled when connecting through TOR by default. So I personally do not think it is a big deal. Certainly not enough of a reason to stop supporting XT especially since other options for increasing the blocksize do not exist yet.
Could you elaborate as to why this makes a difference?
Other options do exist, and others may come still yet. There are just no other options that are in a position to prematurely fork bitcoin.
I misunderstood what you said there, that is why it was a straw man argument, it was not intentional, I am sorry. However if what I was accusing you off was true it would indeed be a very centralizing point of view, that is not the case however and we seem to both agree that having a diversity of clients and development teams is intrinsically a good thing.
It is however not fair to describe my argumentation as "populist tactics" this does not refute the points I make whatsoever. Now when you say "the one alternative presented is the only option". Can you see how this statement is self evidently true, since the one alternative that is presented is by definition the only alternative option at that time. It is actually a binary choice between Core and XT. Because these are the only options we have now. A hypothetical plan to implement something or having proposals to implement something is not the same thing as it actually being in place now. As soon as a third option becomes real I will most likely support that instead especially if it represents a reasonable compromise between these two extreme positions. However faced with this choice as a full node operator and miner, you have to vote, you literally can not do these things without casting a vote to either side, therefore it is impossible to be neutral if you are either mining or running full nodes. The pragmatic reality is that right now we have two choices for the future of Bitcoin which are radically different on fundamental levels.
I have also studied history, sometimes unpredictable things can happen in the world, realities can change quickly sometimes. What concerns me is that if we did have a spike in adoption possibly because of some significant global event, then the network would become overloaded. The consequences of this would seriously hamper adoption and public perception. It would also be much more problematic if we attempted to do a hard fork at short notice when this does become a problem since that would lead to a situation that would be much more chaotic and confusing to most people which, when attempting to do a hard fork would not be a good thing.
"Since it depends on third party trust, it is by definition a trust-adding feature." It does not make the Bitcoin protocol as a whole depend on trust so to speak because it is open source, and these optional features are not fundamental to the Bitcoin protocol itself whatsoever. My point is that because it is optional it does not add trust to the Bitcoin protocol as a whole so to speak. Though because of how XT implements this using a centralized list it does therefore add some trust so to speak to the standart implementation of XT itself, which however is not the same as adding trust on the protocol level of bitcoin, the only fundermental protocol change within Bitcoin XT is BIP101, I will argue that this trust is rather minimal since this feature would only become active if the node is under a DDoS attack which is rather useful. Mike added this feature in response to XT nodes being attacked and he has stated that the list will be generated in a decentralized fassion however that it will take time to develop this. I personally would have thought it would have been better to not add any additional features besides BIP101 since adding anything else does complicate the discussion. Since I am presently running XT nodes that are the BIP101 only version, it would have been better if that was the standard implantation, even if just for political reasons.
"Distrusting XT or BIP 101 =/= trusting the Core development team. That's another blatant mischaracterization that keeps being throw around. Please keep the discussion honest." I did not say that if you distrust BIP101 you therefore trust Core. I said that you should not trust Core, (the same is true for XT). It now seems we are both guilty of using a straw man argument once, if you could admit that you were wrong as well then we would at least both be wise human beings.
"Come again?" to clarify: Since without this feature the full node would not be able to connect or function whatsoever, when under this type of DDoS attack.
"Could you elaborate as to why this makes a difference?" It makes a difference because you can support BIP101 without supporting the other features within XT.
"Other options do exist, and others may come still yet. There are just no other options that are in a position to prematurely fork bitcoin." Again it is self evident in your own statement that there are no other options that are in a position to fork Bitcoin. You think that increasing the block size sometime after January 2016 is prematurely forking Bitcoin, I respectfully disagree, for reasons that I have already stated. The choice that concerns me the most is not increasing the block size, I am glad that we can agree on that.
This article explains very well why increasing the block size would lead to more decentralisation compared to keeping it where it is now:
https://bitcointalk.org/index.php?topic=946236.0I have also written this, read it if you are intrested, it is a more expansive explanation of my views:
https://bitcointalk.org/index.php?topic=1164464.0
