Quote from: VirosaGITS on August 27, 2015, 02:07:44 AM

Quote from: canth on August 27, 2015, 02:03:12 AM

Quote from: VirosaGITS on August 27, 2015, 01:34:29 AM

Quote from: canth on August 27, 2015, 01:26:42 AM

Quote from: VirosaGITS on August 27, 2015, 01:23:48 AM

Quote from: HostFat on August 27, 2015, 01:20:49 AM

The longest chain is what the majority of the network chooses.
If the majority of the network will be on XT or anything else that support BIP101 (or others), than it will be the chain, it will be "the Bitcoin".

We have to see what will happen when the 1MB limit will be reached...

XT isint happening. There's already too much hashpower put toward not accepting XT. So unless XT supporter suddenly buy 75% up from 1% of the total network's hashrate. Its not happening.

This blacklist score being an ip list uploaded by the dev is so shady, there's just no way actual volume of people will support it. Ever.

Yes, because nobody ever changes their minds. Besides, if you're right then what is there to argue about? Seems like a lot of angst about something that has no chance of happening.

Indeed. Nothing to argue about.

I don't think the educated portion of the bitcoin community is going to reverse their decision on a fork that allow the devs to upload an IP black list. That is such a massive security flaw, its no wonder BIP100 gained 30 time the support of XT in 1 day.

Of course that's just what i believe. I could be totally wrong and people may decide to purposely vote in a fork that allow a certain person to destroy bitcoin if he desire.

Aren't you tired of going on and on about a feature that can be disabled by one line? -disableipprio

Nope. I don't like how it allow people to trigger code that deprioritize certain IPs. Just the thought of adding this kind of code is heading down the wrong path.

I have no idea what would be the effect on the network if a portion of the network did not use the default and used -disableipprio instead.

What do you think should happen when a node has all of its incoming connections exhausted? Should the node reject new connections? Drop existing ones? How should they be prioritied? Hearn picked what will work for most, non-Tor using, non-power users. A Tor user is fully capable of turning off the feature and 99% of the other users will never have it engaged since they won't be under attack for incoming connections.

Hell, most users don't even know enough to enable incoming connections through NAT and UPNP is notoriously unreliable even when it's enabled. Basically, this feature will affect very, very few.