... - page 30. | Bitcointalksearch.org

meono

full member

Activity: 196

Merit: 100

Quote from: ?? on ??

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.

meono

full member

Activity: 196

Merit: 100

Quote from: madjules007 on August 19, 2015, 11:56:11 PM

Quote from: meono on August 19, 2015, 11:27:27 PM

Quote from: madjules007 on August 19, 2015, 10:31:49 PM

Quote from: meono on August 19, 2015, 10:07:20 PM

Quote from: 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.

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

full member

Activity: 196

Merit: 100

Quote from: kano on August 19, 2015, 11:21:31 PM

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.

madjules007

sr. member

Activity: 400

Merit: 250

Quote from: meono on August 19, 2015, 11:27:27 PM

Quote from: madjules007 on August 19, 2015, 10:31:49 PM

Quote from: meono on August 19, 2015, 10:07:20 PM

Quote from: 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

full member

Activity: 196

Merit: 100

Quote from: madjules007 on August 19, 2015, 10:31:49 PM

Quote from: meono on August 19, 2015, 10:07:20 PM

Quote from: 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,

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

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.

madjules007

sr. member

Activity: 400

Merit: 250

Quote from: meono on August 19, 2015, 10:07:20 PM

Quote from: 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.

Cryddit

legendary

Activity: 924

Merit: 1132

Quote from: ?? on ??

Quote from: helmax on August 18, 2015, 09:53:31 PM

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.

meono

full member

Activity: 196

Merit: 100

Quote from: 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

madjules007

sr. member

Activity: 400

Merit: 250

Quote from: meono on August 19, 2015, 08:56:53 PM

Quote from: madjules007 on August 19, 2015, 08:46:54 PM

Quote from: Lucko on August 19, 2015, 07:41:27 PM

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.

Quote from: madjules007 on August 19, 2015, 06:23:49 PM

Quote from: meono on August 19, 2015, 06:16:23 PM

Quote from: ?? on ??

Quote from: meono on August 19, 2015, 06:06:26 PM

Quote from: marcus_of_augustus on August 19, 2015, 06:02:34 PM

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.

Quote from: madjules007 on August 19, 2015, 01:44:32 PM

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:

Quote from: madjules007 on August 19, 2015, 01:25:13 PM

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?

meono

full member

Activity: 196

Merit: 100

Quote from: madjules007 on August 19, 2015, 08:46:54 PM

Quote from: Lucko on August 19, 2015, 07:41:27 PM

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

madjules007

sr. member

Activity: 400

Merit: 250

Quote from: Lucko on August 19, 2015, 07:41:27 PM

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.

Soros Shorts

donator

Activity: 1617

Merit: 1012

Quote from: photon_coin on August 19, 2015, 08:07:21 PM

is it even on github ?

Of course it is: https://github.com/bitcoinxt/bitcoinxt

I just downloaded the entire damned repository but have yet to look at a single line of code.

photon_coin

sr. member

Activity: 310

Merit: 256

Photon --- The First Child Of Blake Coin --Merged

really ??

everyone is asking me about this little monster,
guess sooner or later i may have to look it over although i origninally planned not to....

is it even on github ?

mit license >?

Lucko

hero member

Activity: 826

Merit: 1000

Quote from: Klestin on August 19, 2015, 08:00:31 PM

This only happens when the server is full.

By full you mean DOS attacked...

Anyway it is 3:00 am... Sleep...

Klestin

hero member

Activity: 493

Merit: 500

Quote from: ?? on ??

There's a part of the code that describes how it will disconnect you so you reconnect and then it gets your info for the blacklist, that's part of how it compromises tor or proxy anonymity.

You don't understand TOR apparently. The server CAN NOT get your real IP. That's literally the entire point of TOR.

Quote from: ?? on ??

This is for banning IPs, that's not up for debate.

It isn't closed for debate until you show the code that actually bans anything. It does not ban - it reduces priority. When it has too many connections, it picks the lowest priority to disconnect. So, instead of a new plain internet connection being turned away, it may be accepted while one of the TOR connections is dropped. This only happens when the server is full.

Lucko

hero member

Activity: 826

Merit: 1000

Quote from: ?? on ??

Quote from: Lucko on August 19, 2015, 07:46:14 PM

Peter Todd toled the op that he was looking at the wrong code...

I was clicking on view but since you need to do that 100 times I might missed it. Possible... So where I need to press view?

Perhaps the guy with the original email was looking at the wrong area, but in my post I posted code directly from XT, and that's the code I've been discussing.

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23

OK so where is it. Really... Like main.cpp line 20

Lucko

hero member

Activity: 826

Merit: 1000

Quote from: ?? on ??

It would be good if we got skilled & unbiased programmers to analyze this.

Quote from: Lucko on August 19, 2015, 07:24:53 PM

Quote from: ?? on ??

There's a part of the code that describes how it will disconnect you so you reconnect and then it gets your info for the blacklist, that's part of how it compromises tor or proxy anonymity. That's mentioned in the original email from the guy who noticed this, and I saw it in the code.

This is for banning IPs, that's not up for debate. The debate is whether this is just for DoS offenders or if it can be used to blacklist anyone. I think the answer is quite obvious but you guys read the code and decide for yourself.

I'm going to search through the rest of the XT source and see if there's anything else disagreeable. What I posted is just 1 part of the source.

Well no. You posted just a comments not a code. And search didn't find one part...

To say it is for banning you would really need to give me your definition of that. If banning it drooping same TOR connections wham attack from TOR forces you then it really isn't a debate. But if it is anything else it is a lie...

And Peter Todd figure out that he was looking at the wrong code and that code that XT is using will not do that. Read: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010388.html

Peter todd is one of the people who wrote the code, he is not the person who originally reported this on the email list. How is that relevant?

I got that snippet of code you couldnt find out of a copy & paste of the bitcoin XT source code relevant to this. Did you actually click on view in github (link in first post) and go through each part?

Peter Todd toled the op that he was looking at the wrong code...

I was clicking on view but since you need to do that 100 times I might missed it. Possible... So where I need to press view?

Lucko

hero member

Activity: 826

Merit: 1000

Quote from: madjules007 on August 19, 2015, 07:12:39 PM

Quote from: Lucko on August 19, 2015, 06:47:32 PM

Quote from: madjules007 on August 19, 2015, 06:42:28 PM

Quote from: Lucko on August 19, 2015, 06:31:41 PM

Quote from: Greendragon on August 19, 2015, 06:23:15 PM

Quote

So you cant give us any part of the code to support your statement? Yup you're not a programmer just a dumb ass who got told what it is.

Can you bro?

None can. You cant prove an negative only positive. The only way would be to exclude every part of a code... So copy pase the code? But that doesn't help right?

This issue is being used as a red herring. Does no one have a problem with the idea that XT is supposed to address the block size issue, but so much code that is irrelevant to that is being pushed out? We can argue all day about one detail or another -- but can you XT supporters explain why the hell it's all there? And why it's being presented solely as a solution to the block size debate?

Strip it down and stop trying to force other changes down our throats.....

Quote

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?

Not really. XT is compatible with QT now. And it will be with XT and QT+BIP101. You can also run QT+BIP101 if you are worried... And there is a QT made by Mike if you don't like XT. Only BIP101.

That's not really addressing what I said. Yes, I run QT. I'm not really concerned about that and won't change unless forced. I'm concerned about a primarily political push to drive the community to adopt a new protocol under the pretense of a need for larger blocks, but that a) includes other protocol changes (relaying double spends, querying the UTXO set, DNS seed changes, others like the TOR deprioritization code which I still don't quite understand, etc) that aren't widely consented to and b) that the 8MB/double every two years limit does not adequately consider the stake that [largely Chinese] miners with low bandwidth have in the protocol.

Quote from: ?? on ??

This is for banning IPs, that's not up for debate. The debate is whether this is just for DoS offenders or if it can be used to blacklist anyone.

I think this is a fair assessment. Arguing over "banning" vs. "deprioritizing" is playing with semantics. The question I have, as someone who is not particularly technical, is whether there are implications here that go further than simply "deprioritizing TOR nodes that are actively DOS attacking" and haven't really seen an adequate answer.

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

sAt0sHiFanClub

hero member

Activity: 546

Merit: 500

Warning: Confrmed Gavinista

Quote from: Lucko on August 19, 2015, 06:52:15 PM

EDIT: And no idea what you talking about hire

Quote

Not the originating (connecting) peer. Which it wouldn't know anyway because...tor.

I was replying to turtlehuricane.

I think this thread went full retard about an hour ago. But well done in your efforts to explain it. Grin

(last line was trying to explain that the prioritisation refers to the ip of the tor exit node, NOT the ip of your local peer)

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