Topic: ... - page 14. (Read 61003 times)

you mean you feel you are wasting your time parroting the same thing over and over? ... hey, look there's the door

IIRC Luke Jr commented approvingly on reddit (but he admitted that, if XT gets the majority, then it is references to Core that should be censored instead.  I haven't seen any Blockstream guy condemn it. 

And it is not "moderation", but plain censorship, and banning users by the dozen.  They even changed the CSS to suppress reddit's "[deleted]" placeholders (so that the comments often do not seem to make sense). 

Not an inch different than what Pravda's editors would do in the good old days of the USSR.  Or the military government did here 1964-1984.


Of course I do. It is the difference between those spreading baseless FUD, and those repeating it without bothering to understand and check it.


Well, you keep your opinion, I'll keep mine, thank you.

Well, can you say more specifically what is wrong with that quote?


Yes, I know that they intend to use congestion to their advantage, and have explained their plans many times.  That is one of the things that determined my view of them.

If the blacklisting can be disabled or not dosn't really matter.
The problem is that they put in the code for it in the first place.
To me it indicates that the devs are way off track

@madjules077

I indeed am against any form of centralization of authority or responsibility. Even if i'm 100% wrong in it being exploitable in any way. I just don't like the idea of giving any sort of power, useless or not, to any "one". I just feel like negligence, mistake or malice can bring about trouble. Just another vector of attack to exploit.

Although labeling XT corrupted might be a bit of an exaggeration, i just dislike that there is shifty code that doesn't need to be there, is being included in the current hot topic "increasing BTC blocksize".

I feel the IP ban blacklist is kind of arbitrary and doesn't have its place in a decentralized "governance".

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.


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......

WTF!  Anyone with the most vague idea of how spends are constructed,  what coinbase is, and how transactions are verified can easily see how to do this!

Stolfi's been stinking up the place for quite a long time now and claims to be a comp-sci professor who could consult like Peter Todd yet he makes a statement like this?!?  Something isn't adding up here.

Probably not

Just to give a notice to everyone, Gavin for sure is working on Bitcoin from the May 28, 2010, 04:47:08 PM (date of his registration on this forum)
Maybe he was on Bitcoin even before, I can't remember.

I guess i can't blame you. My reason of being vocal is inviting someone to prove me wrong. Thats how i (like to) learn. Or teach.

But doing that i also notice that many users don't even try to learn and change their stance. They instead just "parrot" invalid arguments.

Consider what you said to me to not have fallen into completely deaf ears. (eyes(?))

I'd rather a wallet not add code that may not be necessary or just a temp fix. But i guess XT devs may not be out to destroy Bitcoin. (Maybe, always best to assume everyone's out to get you!)

I starting to hating these users that read just the first post (that can be full of FUD) and waste their time on repeating as a parrot without even reading the few posts that that are just upper their last one.

I feel that just wasting my time in these discussions.

You're pretty spammy, rude and aggressive for a staffer. Aren't you required a minimum of justification in what you post? A minimum of content? A minimum of respect?

I get you have/had a better grasp of the situation than me, than most. And now that i had a mature discussion with someone else, i can now attest to it.

But you really don't contribute anything when you reply spam like "^User is a parrot."

Here a new parrot.

I shall not support XT if it blacklists some ip address.

Well its true that if its just self-defense of a single node its much less of a big deal.

I would have imagined DDoS focusing on the bigger nodes, slowing the overall network significantly, then combined with a TX spam attack. It would have allowed transaction request from Tor nodes to be dropped since they are lower priority and the network would already be saturated with "legit" tx spam.

This would effectively allowing to filter out transaction from the black listed ip range.

A massive attack of such magnitude isint that unlikely when you think of the several government who doesn't like BTC. To me it just seemed like it was another vulnerability.

The only pool producing XT blocks is apparently doing exactly that - just marking them as "XT version" and no more.
See slush's comments about his pool.

But more importantly, no pool in their right mind would be running the XT code yet.
The XT code has been severely lacking in testing compared to normal Core code changes.

Ooooh!

The TX backlog full is different from a DoS attack of connections on the single node.

The code that put in low priority these IP is activated only if the node is getting a DoS attack of connection on itself, only itself.

There isn't any correlation with the amount of TX the it receives from the network and the connections.

Connections =/= TXs

IF a node is under DoS (by receiving many connection from an attacker) then it (only it) will put Tor connections under low priority. (while under attack)
A rightful request from Tor will have to ask connections from one of the other 6000/7000 nodes.

By heavy DoS on the network, do you mean all nodes? If there was, then we'd have a big problem period - doesn't matter if you are on Tor, running XT or core.

If only some nodes are being DoS'ed then it's fine. Tor users would get dropped from certain XT nodes under attack (and that have the anti-DDoS feature enabled). Other XT nodes would not be under attach and would accept Tor connections. In short, it would be fine for Tor users as well as regular users only certain regular users would have fewer problems since they'd have a feature that might reduce the connection attacks.

Not sure why you double posted, but sure. I get what you're saying.

But tell me, if the TX backlog was getting full. Then there was heavy DoS on the network. What would happen to the transactions request from Tor users? Would be still be processed at some point, even when the BTC system is inclined to drop off transactions that will not make it to a block after X conditions are met?

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.

LOL. Seriously...your logic is seriously lacking. How would anyone know what IP addresses transactions are going to come from before they are transmitted? Maybe they do this magic IP address <-> Bitcoin address lookup in the sky?