...

[marcus_of_augustus]

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

Again point to it. It is impossible to show that something doesn't exist since there is nowhere to point to that shows that. But if you show me where you think it is I can show you why you are wrong... To this point none did that.

He has at least 3 major commits in XT that have been refused from Core that have nothing to do with blocksize. I don't even need to point to any of them because this is well known.

[Hazir]

I don't like this. I don't like this at all, I was preaching in the past about government involvement in the bitcoin and it is happening - disguised as security option.
Things that restrict and limit you are always camouflaged as tools crafted to make you safe, it is disgusting approach. What we are seeing now is a lot like government action against bitcoin, including the core protocol.

[Lucko]

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?

Rite my friend

So you agree that he needs to show where this is. Negative is that this is not in a code. Positive is to show it...

[madjules007]

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

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?

[Lucko]

I don't like this. I don't like this at all, I was preaching in the past about government involvement in the bitcoin and it is happening - disguised as security option.
Things that restrict and limit you are always camouflaged as tools crafted to make you safe, it is disgusting approach. What we are seeing now is a lot like government action against bitcoin, including the core protocol.

So where is that part. Let me know... Not in a code... To this moment none show the part of the code that do this...

[Lucko]

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

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.

[sAt0sHiFanClub]

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.

The offending comment and code you mentioned :

Code:

//A group of logically related IP addresses. Useful for banning or deprioritising sources of abusive traffic/DoS attacks.

...  refers to Tor proxy peers. Not the originating (connecting) peer. Which it wouldn't know anyway because...tor.

[Lucko]

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.

The offensive comment and code you mentioned :

Code:

//A group of logically related IP addresses. Useful for banning or deprioritising sources of abusive traffic/DoS attacks.

...  refers to Tor proxy peers. Not the originating (connecting) peer. Which it wouldn't know anyway because...tor.

Yes just a coment. But it is "Useful for banning or deprioritising" not "Will be used for banning and deprioritising"

The code then uses it for "deprioritising" but not for "banning" when attacked from TOR

You can't use only one line

EDIT: And no idea what you talking about hire

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

[madjules007]

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

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.

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. 

[Lucko]

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

[sAt0sHiFanClub]

EDIT: And no idea what you talking about hire

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. 

(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)

[Lucko]

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

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.

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

[Lucko]

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

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]

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

[Klestin]

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.

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]

This only happens when the server is full.

By full you mean DOS attacked...

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

[photon_coin]

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

[Soros Shorts]

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.

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

[meono]

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