Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)
Bitcoin is a trust less protocol, one of the great innovations behind Bitcoin is that we can achieve trust without centralized authority. However when people start thinking in terms of who they should trust for the development of the Bitcoin protocol then we are already in trouble, since this comes from a fundamental misunderstanding of how Bitcoin governance should work.
This is only a problem if people grant affirmative trust. By default, we trust no one. Expressing distrust of Gavin and Hearn is not problematic at all. Hearn has a history of pushing proposals that are very antithetical to bitcoin, and that would put its fungibility (and therefore any value attributed to bitcoin) at great risk. Gavin's opinions show that he lacks the technical foresight to plan for all contingencies in scaling bitcoin's capacity by 8000x over 20 years, and his rhetoric around the XT project make it clear that he values his personal vision of a scaled consumer payment protocol far above consensus.
When it is clear that our ethics and beliefs (political or technical) are at odds, distrust has a fine connotation.
The problem I see is more so this-- People have largely been persuaded in favor of increasing the block size limit, but since XT/BIP 101 is the only implementation that can be hard forked at this time, people conflate their support of increasing block size with support of XT. In many cases, it's clear that this has resulted in blind trust of Gavin and Hearn, particularly exhibited when people defend centralizing / trust-adding features that are built into XT.
Here's a good post that spells out why the TOR IP list issue -- even though substantively not a problem yet -- is legitimately controversial. It is a centralized solution based on trust that is completely unnecessary. Yet it is clear as day from the rhetoric around here that XT supporters are justifying this as a non-issue -- no matter how antithetical it is to bitcoin -- because they are so loyal to XT.
@VirosaGITS
LOL
You can even add all the possible IPs to the list, then they will have all the same priority, and just during a DoS attack
Do you know that will happen when a dev will add other IP to this list? Someone will see it because ... it's an open source project!
Do you check every day what devs add to the Bitcoin Core?
Again, it isn't a black list, it is a "low priority list", that enable it self only IF there is a DoS attack.
LOL
You can even add all the possible IPs to the list, then they will have all the same priority, and just during a DoS attack
Do you know that will happen when a dev will add other IP to this list? Someone will see it because ... it's an open source project!
Do you check every day what devs add to the Bitcoin Core?
Again, it isn't a black list, it is a "low priority list", that enable it self only IF there is a DoS attack.
Actually, it fits the definition of a blacklist quite well, particularly if you consider why the list was compiled in the first place:
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=definition+blacklist
But this is just a silly semantic issue.
The larger issue is this: Why do people keep rationalizing a centralized solution to DDOS attacks? Compiling a centralized list introduces trust into an otherwise trustless system. That's downright foolish.
There is nothing wrong with deprioritizing IP addresses that are maliciously attacking you. Why don't we stick with that? Why can't a node determine when an IP address is spamming it, and deprioritize its access on that basis? Perhaps we can make it even easier for nodes to do that. What possible reason is there to justify using a [trusted] third party to compile a list of suspicious IP addresses that nodes will trust simply by virtue of running a node?
If there is a problem, use a decentralized solution. Nodes should be capable of identifying IP addresses that are attacking them without introducing third party trust.
Quote
Currently Tor exits are labelled as being lower priority than regular IP addresses, as jamming attacks via Tor have been observed
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, so we can oppose this aspect of the XT implementation hand in hand and move onto the next issue of contention......