...

[madjules007]

It is for everyone on TOR whan TOR is DOSing... Just read the code. When you get 125 connections on a core it will start drooping TOR connections if any unTOR connection will come in. So even when DOSed it will not drop all... nonTOR is prioritized because there are Exchanges and Wallets and Payment processors there...

Need bigger blocks... Well do we need IPv6... Wouldn't it be grate if we done that way back... It cost so much more now then it would...

DNS seed changes
I really don't see a problem removing one that isn't working and adding himself...

querying the UTXO set
Did read what XT says about it but did not have time to do more research. If I don't like it I can still use QT+BIP101. But you can tell me the issue...

relaying double spends
Did read what XT says about it but did not have time to do more research. If I don't like it I can still use QT+BIP101. But you can tell me the issue...

That's the point. The people in this thread pushing hard for XT aren't even aware of some of the changes that it makes to the protocol. That's a function of this sense of urgency to address the block size issue -- but then, what is the urgency to implement any other changes? There is none.

Why is it so difficult to understand that the hard fork should be taken on its own -- it shouldn't be attempting to implement a slew of other changes that Gavin and Hearn want. I hate to bring up the Patriot Act analogy again but the urgency there was much the same -- "We urgently need to address new threats (block size limit), but we're gonna make a bunch of other changes behind the scenes without any public debate. All the while, we only discuss the block size limit, and we only do it with polemics."

Yes, we need bigger blocks. That is somewhat of an urgent concern. There are no other concerns that call for this urgency. Why blindly support a hard fork that ignores that?

This is a hard fork, not a fucking salad bar.

You claimed you're a nontechnical user yet you like to argue about crap you dont understand.

This antiDoS   doesnt change the protocol one bit.

The bitcojnXT project started long before this blocksize increase. It is just a bitcoin wallet forked from core with extra features ( including this particular feature) and fully working with blockchain protocol.

Bitcoin XT now include BIP101 because the core devs cant come to an agreement.

If you dont understand, ask . do not assume and speak out in the room. All noise no signal

Oh, don't mind me. I'm just a bitcoin user sine 2011, running a full node since 2012. Fuck me, right?

Sorry that you don't seem to understand that the point I am making is philosophical, not technical. The urgent issue is block size. The fork shouldn't be used as an opportunity to capitalize on sentiment around the block size limit in order to push "other features" that core developers disagreed with.

I've asked many questions in this thread, and most went unanswered. You and others have repeatedly ignored everything I've said and asked,  and responded with generic answers in support of XT.

Do not assume? I'm not. Im questioning. If you do not approach this with skepticism, I feel bad for you. What I have seen is that several people in this thread backing XT that can't explain what the other code changes (besides block size limit) are and what purpose they serve.

If you're trying to persuade people to your view, you're doing a really bad job. You've offered nothing to suggest that you have technical expertise, and you are very abusive.

Why does Hearn want to cram huge controversial poison-pill commits into XT along with the popular blocksize commit of Gavin's is the real question.

It's like those politicians cramming all the surveillance shit in the "Schumer Bill For The Protection of Widows Orphans and Kiddies."

Its a rule that you can turn off anytime. Reason its a controversy because someone make it be.

The XT was under DDoS attack, he had to write a defense mechanism quick. This feature does not affect anyone's privacy. You cant let emotion and prejudice to blind you

It logs your IP and potentially puts it on a blacklist, even if you're on tor or a proxy. That is the definition of compromising privacy.

Yet you cant back your statement with a code right?

Yup thats what i guess

The debate is about block size. Can you show me the section of the XT code that addresses block size? Then, can you show me everything else in the code? Then explain why such code is being included in a fork that is supposed to address block size?

Let's not get bogged down by the details. What the hell are these pages and pages of code that have absolutely fuck all to do with block size? And why is it being pushed then solely as a fix for the block size issue?

The issue here is philosophical first and foremost -- secondarily, it's what's actually in the code.

So much ad hominem in this thread. So little evidence of technical knowledge. There are real concerns here, and some of us have quite a lot of money on the line. It's nice that there is so much support for XT in this thread, I guess, but perhaps some of you guys could take a moment to answer some questions from a non-technical guy:

I understand that this is being framed as "protection from DOS attacks from TOR nodes." Can anyone explain to me why this is necessary? Has DOS attack by the TOR network ever been a real threat -- and if so, could one provide proof? TOR nodes are easily tracked, easily blacklisted. Aren't serious DOS attacks run off botnets? How does this code actually prevent DOS attacks? It merely "deprioritizes" (to zero access?) IP addresses by mere association.

Is DOS a real threat to the bitcoin network? If so, how does effectively IP banning TOR nodes do anything to address that? This is like setting a mouse trap for a plague of locusts. I'm at a loss for how this provides security to the network. At best it seems extraneous, at worst..... let's just say, I don't know that this list will be limited to TOR nodes. And I am concerned that targeting nodes and denying access to the network based on IP address could be a slippery slope when new commits come along down the road.

On what basis are IP addresses deprioritized? Who decides what addresses/batches of addresses are deprioritized? Can this deprioritization be used to prevent nodes from accessing the network entirely? This is supposedly about the TOR network -- though I'd like to see some evidence that the TOR network poses any threat whatsoever to the bitcoin network. Could this potentially be used to target other groups of nodes on some other basis, regional or otherwise?

[1713960527]

1713960527

[meono]

.......

Start with bitcoinxt.software.

You're welcome. And dont come back until you actually read all of it.

No one persuade you here, find out on your own. This isnt an election campaign

[Cryddit]

This code doesn't actually block anything, just marks it as being lower priority than non-Tor traffic. It should never do anything unless there's an active DoS attack via Tor. So perfect accuracy isn't really needed here: Tor access still works fine and will do even if you run a Bitcoin node and Tor node on the same machine.

That said, I'll make a mental note to switch to the second URL when I work on this code again (might be soon, given the ongoing DoS attacks via Tor we're seeing).

It explicitly says it disconnects addresses with low to negative priority.

This would be the first time in history that anyone was blacklisted from using Bitcoin if XT forks, it's a big deal and against the fundamental reasons Bitcoin is used.

Bitcoin core has always disconnected addresses with low to negative priority. 

You get low to negative priority by engaging in things that facilitate DoS attacks. 

Because a DoS attack carried out through Tor nodes will be distributed across all Tor exit nodes, the old protocol (which would lower the priority of a single tor exit node) isn't meaningful protection for a DoS attack via Tor. 

The mods you're looking at treat all Tor connections as having the same priority, so that a DoS attack via Tor will affect all of the Tor exit nodes at the same time.   If you're making no attempt to tell the difference between individual Tor users, that's the best you can do to protect the network. 

If they were trying to unmask Tor users I'd be sort of upset.  But there's no attempt to do that.  They're just trying to give the network the same degree of protection from DoS attacks via Tor that it has from DoS attacks via open IPs.

[madjules007]

.......

Start with bitcoinxt.software.

You're welcome. And dont come back until you actually read all of it.

No one persuade you here, find out on your own. This isnt an election campaign

I looked at it. I can't begin to understand it from a technical perspective. If you think that anyone involved with bitcoin or running a node should also be a coder, you must have a very grim view of future bitcoin adoption.

Election campaign -- apparently it is. It's highly politicized and polemic. And we are left with two binary options. And here you are, day and night in every thread on the Disussion subforum insulting and yelling down anyone who questions or opposes the way XT has been rolled out (without providing any explanation or technical knowledge no less)... mudslinging. And in the end, nodes (like the one I run) will "vote" for whether or not to let XT move forward.

Thanks for all your help. But what happened to "If you dont understand, ask"? The fact is that you're just here mindlessly shilling.

[kano]

Code:

{
    "version" : 100200,
    "protocolversion" : 70002,
    "blocks" : 370651,
    "timeoffset" : -1,
    "connections" : 124,
    "proxy" : "",
    "difficulty" : 52699842409.34700775,
    "testnet" : false,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00001000,
    "errors" : ""
}

So ... if I was running XT at the moment, I would effectively have a blacklist of IPs in there each time someone connects ... anyone in that blacklist of IP addresses being dropped each time someone not in that list connects.
Yes I do actually randomly DROP connections, with my firewall, that have a low "blocks=" when they connect so that bitcoind is getting connections all the time and staying at 124/125
... so it's certainly not a case of ONLY happening with a DDOS

But irrelevant of that, it's a blacklist.
Distributing software with an IP blacklist in it is what XT is doing.

Feel free to argue semantics, but it's a blacklist of IP addresses.

[meono]

.......

Start with bitcoinxt.software.

You're welcome. And dont come back until you actually read all of it.

No one persuade you here, find out on your own. This isnt an election campaign

I looked at it. I can't begin to understand it from a technical perspective. If you think that anyone involved with bitcoin or running a node should also be a coder, you must have a very grim view of future bitcoin adoption.

Election campaign -- apparently it is. It's highly politicized and polemic. And we are left with two binary options. And here you are, day and night in every thread on the Disussion subforum insulting and yelling down anyone who questions or opposes the way XT has been rolled out (without providing any explanation or technical knowledge no less)... mudslinging. And in the end, nodes (like the one I run) will "vote" for whether or not to let XT move forward.

Thanks for all your help. But what happened to "If you dont understand, ask"? The fact is that you're just here mindlessly shilling.

Its only politics because you make it to be.

Again to choose which side you must fully understand, and dont just listen to FUD or let prejudice affect your decision. You dont vote who wrote the code, you only vote to use the code. FUD like this is nothing but to attack Mike with agenda.

Another tip is dont call someone a shill because they understand the topic better than you. You cant keep calling everyone with opposite view, shills or trolls. No one will care to spoodfeed you when you ask questions,

[madjules007]

.......

Start with bitcoinxt.software.

You're welcome. And dont come back until you actually read all of it.

No one persuade you here, find out on your own. This isnt an election campaign

I looked at it. I can't begin to understand it from a technical perspective. If you think that anyone involved with bitcoin or running a node should also be a coder, you must have a very grim view of future bitcoin adoption.

Election campaign -- apparently it is. It's highly politicized and polemic. And we are left with two binary options. And here you are, day and night in every thread on the Disussion subforum insulting and yelling down anyone who questions or opposes the way XT has been rolled out (without providing any explanation or technical knowledge no less)... mudslinging. And in the end, nodes (like the one I run) will "vote" for whether or not to let XT move forward.

Thanks for all your help. But what happened to "If you dont understand, ask"? The fact is that you're just here mindlessly shilling.

Its only politics because you make it to be.

Again to choose which side you must fully understand, and dont just listen to FUD or let prejudice affect your decision. You dont vote who wrote the code, you only vote to use the code. FUD like this is nothing but to attack Mike with agenda.

Another tip is dont call someone a shill because they understand the topic better than you. You cant keep calling everyone with opposite view, shills or trolls. No one will care to spoodfeed you when you ask questions,

No, it's political because Gavin went off on his own and tried to fork bitcoin when core devs didn't take to his ideas, polarizing the community. And because certain parties sought to force the debate by spamming the blockchain; investors, speculators and the media are drawing a connection between this XT drama and the return to a bear market. It's political because Gavin's approach is "my way or the highway" when many do not support his ideas.

Hence you making hundreds of posts, doing very little but making baseless ad hominems and insulting people left and right, while not showing any evidence whatsoever that you "understand the topic better than" anyone. You simply keep repeating that you do. I didn't take this "FUD" without a grain of salt, and I was merely questioning the way it was carried out, and whether some of the changes were necessary given the contentious nature of this debate. Many of the points I was raising -- which you have not addressed -- do not require a technical understanding, so that point is moot anyway. And don't get it twisted; I wasn't calling anyone in here a shill but you.

[meono]

Code:

{
    "version" : 100200,
    "protocolversion" : 70002,
    "blocks" : 370651,
    "timeoffset" : -1,
    "connections" : 124,
    "proxy" : "",
    "difficulty" : 52699842409.34700775,
    "testnet" : false,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00001000,
    "errors" : ""
}

So ... if I was running XT at the moment, I would effectively have a blacklist of IPs in there each time someone connects ... anyone in that blacklist of IP addresses being dropped each time someone not in that list connects.
Yes I do actually randomly DROP connections, with my firewall, that have a low "blocks=" when they connect so that bitcoind is getting connections all the time and staying at 124/125
... so it's certainly not a case of ONLY happening with a DDOS

But irrelevant of that, it's a blacklist.
Distributing software with an IP blacklist in it is what XT is doing.

Feel free to argue semantics, but it's a blacklist of IP addresses.

That "blacklist IP" are all TOR connections not clearnet IPs.

His code is only to prioritize TOR IPs. And thus clearnet IPs has the highest Priority.

So if the new connection is a TOR connection then the scheduling algorithm starts. Its not perfect but it works against Tor DoS attack.

The key point, its no way in any shape or form " a blacklist" This is not semantic game. I expect better from you Kano, you're my fav cgminer dev.

[meono]

.......

Start with bitcoinxt.software.

You're welcome. And dont come back until you actually read all of it.

No one persuade you here, find out on your own. This isnt an election campaign

I looked at it. I can't begin to understand it from a technical perspective. If you think that anyone involved with bitcoin or running a node should also be a coder, you must have a very grim view of future bitcoin adoption.

Election campaign -- apparently it is. It's highly politicized and polemic. And we are left with two binary options. And here you are, day and night in every thread on the Disussion subforum insulting and yelling down anyone who questions or opposes the way XT has been rolled out (without providing any explanation or technical knowledge no less)... mudslinging. And in the end, nodes (like the one I run) will "vote" for whether or not to let XT move forward.

Thanks for all your help. But what happened to "If you dont understand, ask"? The fact is that you're just here mindlessly shilling.

Its only politics because you make it to be.

Again to choose which side you must fully understand, and dont just listen to FUD or let prejudice affect your decision. You dont vote who wrote the code, you only vote to use the code. FUD like this is nothing but to attack Mike with agenda.

Another tip is dont call someone a shill because they understand the topic better than you. You cant keep calling everyone with opposite view, shills or trolls. No one will care to spoodfeed you when you ask questions,

No, it's political because Gavin went off on his own and tried to fork bitcoin when core devs didn't take to his ideas, polarizing the community. And because certain parties sought to force the debate by spamming the blockchain; investors, speculators and the media are drawing a connection between this XT drama and the return to a bear market. It's political because Gavin's approach is "my way or the highway" when many do not support his ideas.

Hence you making hundreds of posts, doing very little but making baseless ad hominems and insulting people left and right, while not showing any evidence whatsoever that you "understand the topic better than" anyone. You simply keep repeating that you do. I didn't take this "FUD" without a grain of salt, and I was merely questioning the way it was carried out, and whether some of the changes were necessary given the contentious nature of this debate. Many of the points I was raising -- which you have not addressed -- do not require a technical understanding, so that point is moot anyway. And don't get it twisted; I wasn't calling anyone in here a shill but you.

Thats your perspective due to your lack of understanding the issue. Its not my way or highway, its due to one side refuse to compromise to come to an agreement.

The issue has been discussed since 2013. The key part you dont understand about Bitcoin is: Bitcoin is the consensus network. Not the core development team. In other words Bitcoin is a system designed to find consensus. There are many discussions around this topic (consensus and hard forks) in 2010, i was actually part of the discussion when we first talked about hard forks. I will find time to make a thread to quote you some contradicting views that now the core devs have. Despite that my account is new, i'm not new. And no i dont make this account to hide. I dont have to. If i can post with my original account i would.


Yes i do insult other members when its clearly their agenda is to spread BS and attack the opposite side. They werent here to see everything. To me ditching and trashing Gavin because of some conspiracy is a disgrace of this community.

[meono]

It's not tor only, just there is specific code to see through tor. I'm still curious if this software would ban relay IPs, that would greatly inhibit the tor network's ability to use bitcoin. If 1 of the relays you go through is banned then it probably wouldn't work. And 1 attack could get a bunch of relays banned.

Again, it does not "ban", it only lower the priority of that IP relay. And it should only do it when there is DoS attack thro Tor.

Keep using ban and blacklist words , but got no clue of what the actual scheduling algorithm does?

Mike or ANYONE can patch this code with better tool such as this one: https://check.torproject.org/torbulkexitlist

So it does not penalize clearnet peer connection from the same IP relay of the Tor connection.

[marcus_of_augustus]

Yes i do insult other members when its clearly their agenda is to spread BS and attack opposite sides. They werent here to see everything. To me ditching and trashing Gavin because of some conspiracy is a disgrace of this community.

ummm , I think he's disgraced himself by his actions. When the puppy pees on the rug he needs to be put outside and think about what he has done before he can rejoin the circle.

https://www.youtube.com/watch?v=QHJGoZpFeM8

[Cryddit]

They certainly put IPs on a blacklist, whether it's only DoS attackers or more than that is up for debate, we need a technical expert to go through it to confirm.

They put tor exit nodes on a list.  That list does not function as a black list until or unless a DoS attack starts coming from tor exit nodes and it gets bad enough that the Tor-Exit-Nodes-List gets banned.

If someone is carrying out a DoS attack via Tor, it will disconnect all Tor users rather than only disconnecting the ones performing the attack. 

This is because the people implementing it have no desire to break Tor.  If there was a serious effort to ban only the Tor users perpetrating the DoS attack, that would require breaking Tor anonymity to figure out what users those were.  If you don't make any attempt to break Tor anonymity (and they don't) then you have to treat all Tor connections as equal.

I'm annoyed that they tried to do this at the same time as the block size issue - the block size change would have gone through without a problem if left to adoption rather than blockstream shills screaming about it.  It was plain bad judgment to do anything else at the same time though, because now the block stream shills get to scream FUD about something else in order to fight the block size increase.  I guarantee they wouldn't give a crap about it if the block size increase had already gone through, bitcoin had been made scalable without them, and their fucking expensive business plan which they're trying to build by increasing transaction expenses for everybody, was already in the toilet.

Bitcoin exists for purposes beyond making a profit  for Blockstream. 

[meono]

They certainly put IPs on a blacklist, whether it's only DoS attackers or more than that is up for debate, we need a technical expert to go through it to confirm.

They put tor exit nodes on a list.  That list does not function as a black list until or unless a DoS attack starts coming from tor exit nodes and it gets bad enough that the Tor-Exit-Nodes-List gets banned.

If someone is carrying out a DoS attack via Tor, it will disconnect all Tor users rather than only disconnecting the ones performing the attack. 

This is because the people implementing it have no desire to break Tor.  If there was a serious effort to ban only the Tor users perpetrating the DoS attack, that would require breaking Tor anonymity to figure out what users those were.  If you don't make any attempt to break Tor anonymity (and they don't) then you have to treat all Tor connections as equal.

I'm annoyed that they tried to do this at the same time as the block size issue - the block size change would have gone through without a problem if left to adoption rather than blockstream shills screaming about it.  It was plain bad judgment to do anything else at the same time though, because now the block stream shills get to scream FUD about something else in order to fight the block size increase.  I guarantee they wouldn't give a crap about it if the block size increase had already gone through, bitcoin had been made scalable without them, and their fucking expensive business plan which they're trying to build by increasing transaction expenses for everybody, was already in the toilet.

Bitcoin exists for purposes beyond making a profit  for Blockstream. 

Very true, and our former friend, Theymos also supported this idea.

[Mobius]

This needs more exposure! I don't understand why the Core team won't just double size to 2mb and end this nonsense. In a few years time, we can re-visit the issue and possibly bump it up to 4mb if there are still no solutions. The devs are acting like babies.

[meono]

This needs more exposure! I don't understand why the Core team won't just double size to 2mb and end this nonsense. In a few years time, we can re-visit the issue and possibly bump it up to 4mb if there are still no solutions. The devs are acting like babies.

look like you have lots to read about

Have fun

[bitboy11]

It explicitly says it disconnects addresses with low to negative priority.

This would be the first time in history that anyone was blacklisted from using Bitcoin if XT forks, it's a big deal and against the fundamental reasons Bitcoin is used.

Thanks for this...it is a definite eye-opener!

[Amph]

This needs more exposure! I don't understand why the Core team won't just double size to 2mb and end this nonsense. In a few years time, we can re-visit the issue and possibly bump it up to 4mb if there are still no solutions. The devs are acting like babies.

look like you have lots to read about

Have fun

what's the real problem in upgrading core with a bigger blocksize? i have not seen any other counter argument for this, why instead of making a new "alternative client", we simply go ahead and push the block size on core, it sounds so simple and less troublesome

and it would have saved us all this mess and the crash of bitcoin which was holding really nice until this shit has come out...

[Mitchell]

The code isn't hard to find at all and clearly exist, so please stop saying that it doesn't.

Code:

#ifndef BITCOIN_CIPGROUPS_H
#define BITCOIN_CIPGROUPS_H

#include "netbase.h"

class CScheduler;

// A group of logically related IP addresses. Useful for banning or deprioritising
// sources of abusive traffic/DoS attacks.
struct CIPGroupData {
    std::string name;
    // A priority score indicates how important this group of IP addresses is to this node.
    // Importance determines which group wins when the node is out of resources. Any IP
    // that is not in a group gets a default priority of zero. Therefore, groups with a priority
    // of less than zero will be ignored or disconnected in order to make room for ungrouped
    // IPs, and groups with a higher priority will be serviced before ungrouped IPs.
    int priority;

    CIPGroupData() : priority(0) {}
};

Source: https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
File: src/ipgroups.h
Lines: 5 to 24.

It can be found in the master and the latest release of Bitcoin XT:
https://github.com/bitcoinxt/bitcoinxt/blob/master/src/ipgroups.h
https://github.com/bitcoinxt/bitcoinxt/blob/0.11A/src/ipgroups.h

[sAt0sHiFanClub]

It explicitly says it disconnects addresses with low to negative priority.

This would be the first time in history that anyone was blacklisted from using Bitcoin if XT forks, it's a big deal and against the fundamental reasons Bitcoin is used.

Thanks for this...it is a definite eye-opener!

It sure was. >How one person can so misinterpret a few lines of code so badly is beyond most. Especially when he freely admits he doesn't understand the code and how tor peers work. Yet when propeller heads from both sides explain it, he persists.

[valiz]

I am amased of the army of XT shill trolls in this thread trying to deny the obvious.  . But this IP/Tor blacklisting and connecting to torproject with "Bitcoin XT" user agent stinks so bad that even a 100 troll army can't cover it up.   

Anyway, the block size increase is not so urgently required as the XT supporters make you think. We can go on for a couple of years until consensus is reached in Bitcoin Core. But this is a debate for another thread.

OMG urgent problem! here is the solution! don't mind the privacy killing code, it's for your own protection and you can disable it if you want