...

[miragecash]

Posting here in the English forum will not help. The majority of Bitcoin mines are in China, Hong Kong, and Iceland.  I used Google translate to post it in the Chinese section, but Google translate really sucks. If you know Chinese, please translate this post and put it in the Chinese section. Thanks.

My sucky Chinese post: https://bitcointalk.org/index.php?topic=1166667.msg12284427#msg12284427

Thanks Check2fire for catching this. It's very serious and every Bitcoiner needs to see. This threatens the very fundamentals of Bitcoin.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010379.html

Bitcoin XT contains an unmentioned addition which periodically downloads
lists of Tor IP addresses for blacklisting, this has considerable privacy
implications for hapless users which are being prompted to use the
software. The feature is not clearly described, is enabled by default,
and has a switch name which intentionally downplays what it is doing
(disableipprio). Furthermore these claimed anti-DoS measures are
trivially bypassed and so offer absolutely no protection whatsoever.

Connections are made over clearnet even when using a proxy or
onlynet=tor, which leaks connections on the P2P network with the real
location of the node. Knowledge of this traffic along with uptime metrics
from bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will
cause them to make a new request to the blacklist endpoint via the
clearnet on relaunch at the same time their P2P connections are made
through a proxy. Requests to the blacklisting URL also use a custom
Bitcoin XT user agent which makes users distinct from other internet
traffic if you have access to the endpoints logs.

Mike Hearn says it's to ban people who use DoS attacks from the network, but obviously it can be used to blacklist anyone.

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

[1715615342]

1715615342

[uxgpf]

Wow, this is fucked up and props to turtlehurricane for disclosing this Very important piece of information!

I have not read the whole thread yet, don't hate, I just came here after seeing BayAreaCoin's signature. Had to post to follow along with it in my subscribed threads and so I can catch up and read through what I've missed. Damn, drama on BitcoinTalk is so time consuming with 2 kids sometimes, but I always love to follow along and "be in the know"!

I'll spare you from reading. (if you have time, go ahead though.)

In case Bitcoin XT node comes under DDOS attack and connections get filled it will decrease priority of IP-adresses of known TOR exit nodes, thus dropping them in favor of non TOR connections. You can disable this feature if you think it's not a good idea or even use client that doesn't contain it (BIP 101 only).

The code doesn't compromise your privacy. If you run a node your IP address is visible on the clearnet anyway (how do you think other peers connect to you) and if you are behind a proxy or using TOR this code won't run.


@miragecash If you want to spread information instead of FUD, please just post a link to the original discussion and not turtlehurricane's hand picked quote, which has been shown to be incorrect information. (it's rebuked in the very same thread you link to)

[Carlton Banks]

Wow, this is fucked up and props to turtlehurricane for disclosing this Very important piece of information!

I have not read the whole thread yet, don't hate, I just came here after seeing BayAreaCoin's signature. Had to post to follow along with it in my subscribed threads and so I can catch up and read through what I've missed. Damn, drama on BitcoinTalk is so time consuming with 2 kids sometimes, but I always love to follow along and "be in the know"!

I'll spare you from reading. (if you have time, go ahead though.)

By sowing more disinformation?

In case Bitcoin XT node comes under DDOS attack and connections get filled it will decrease priority of IP-adresses of known TOR exit nodes, thus dropping them in favor of non TOR connections. You can disable this feature if you think it's not a good idea or even use client that doesn't contain it (BIP 101 only).

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

The code doesn't compromise your privacy. If you run a node your IP address is visible on the clearnet anyway (how do you think other peers connect to you) and if you are behind a proxy or using TOR this code won't run.

Does a hardcoded list of permissible TOR exit nodes compromise privacy? Can I get a "hell yes"? (link to the XT relevant code, conveniently, is a few posts above)

[brg444]

Wow, this is fucked up and props to turtlehurricane for disclosing this Very important piece of information!

I have not read the whole thread yet, don't hate, I just came here after seeing BayAreaCoin's signature. Had to post to follow along with it in my subscribed threads and so I can catch up and read through what I've missed. Damn, drama on BitcoinTalk is so time consuming with 2 kids sometimes, but I always love to follow along and "be in the know"!

I'll spare you from reading. (if you have time, go ahead though.)

By sowing more disinformation?

In case Bitcoin XT node comes under DDOS attack and connections get filled it will decrease priority of IP-adresses of known TOR exit nodes, thus dropping them in favor of non TOR connections. You can disable this feature if you think it's not a good idea or even use client that doesn't contain it (BIP 101 only).

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

The code doesn't compromise your privacy. If you run a node your IP address is visible on the clearnet anyway (how do you think other peers connect to you) and if you are behind a proxy or using TOR this code won't run.

Does a hardcoded list of permissible TOR exit nodes compromise privacy? Can I get a "hell yes"? (link to the XT relevant code, conveniently, is a few posts above)

More importantly it compromises trust as it necessarily introduces a third-party who manages this list.

[uxgpf]

By sowing more disinformation?

That wasn't my intention, but maybe some willful ignorance on my part. (which is probably just a bad)
Anyway, thanks for reply and making me understand the issue better.

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

You're right, if I understood it correctly, when XT node is under DDoS attack and your node connects to it via TOR it would drop your connection. In normal circumstances that shouldn't happen though.

As you say you cannot control the behaviour of other nodes so such code would probably be better disabled by default. (if someone wants protection from DDoS attacks coming through TOR they could enable it, but as default all peers would be treated the same)

Does a hardcoded list of permissible TOR exit nodes compromise privacy? Can I get a "hell yes"? (link to the XT relevant code, conveniently, is a few posts above)

See above.

[Carlton Banks]

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

You're right, if I understood it correctly, when XT node is under DDoS attack and your node connects to it via TOR it would drop your connection. In normal circumstances that shouldn't happen though.

As you say you cannot control the behaviour of other nodes so such code would probably be better disabled by default. (if someone wants protection from DDoS attacks coming through TOR they could enable it, but as default all peers would be treated the same)

Does a hardcoded list of permissible TOR exit nodes compromise privacy? Can I get a "hell yes"? (link to the XT relevant code, conveniently, is a few posts above)

See above.

See above? No. The whitelisted exit nodes is not a feature you can turn on and off like the DDOS deprioritising. It's permanently on, at least in XT version 0.1

I did say "hardcoded". "hardcoded" means pretty much what it sounds like. I don't mean to trounce everything you say, but it was essentially all wrong, so you didn't leave me much choice.

[brg444]

By sowing more disinformation?

That wasn't my intention, but maybe some willful ignorance on my part. (which is probably just a bad)
Anyway, thanks for reply and making me understand the issue better.

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

You're right, if I understood it correctly, when XT node is under DDoS attack and your node connects to it via TOR it would drop your connection. In normal circumstances that shouldn't happen though.

As you say you cannot control the behaviour of other nodes so such code would probably be better disabled by default. (if someone wants protection from DDoS attacks coming through TOR they could enable it, but as default all peers would be treated the same)

Does a hardcoded list of permissible TOR exit nodes compromise privacy? Can I get a "hell yes"? (link to the XT relevant code, conveniently, is a few posts above)

See above.

See my reply before yours. The privacy issue is really behind the point. The gist of the problem is that this introduces unnecessary trust as these "lists" are necessarily maintained by a third-party.

[uxgpf]

More importantly it compromises trust as it necessarily introduces a third-party who manages this list.

I think the code which downloads IP-addresses from TOR was replaced by a hardcoded list, though it would seem more reasonable if such list was fetched from a configuration file instead. Hardcoding IP-addresses seems just stupid.

[Carlton Banks]

More importantly it compromises trust as it necessarily introduces a third-party who manages this list.

I think the code which downloads IP-addresses from TOR was replaced by a hardcoded list, though it would seem more reasonable if such list was fetched from a configuration file instead. Hardcoding IP-addresses seems just stupid. (or is there something I don't understand)

Config file is Hearn's stated plan. It's still a bad idea, most people will not touch the defaults. Also, I will believe it when I see it, this is Mike we're talking about.

[uxgpf]

More importantly it compromises trust as it necessarily introduces a third-party who manages this list.

I think the code which downloads IP-addresses from TOR was replaced by a hardcoded list, though it would seem more reasonable if such list was fetched from a configuration file instead. Hardcoding IP-addresses seems just stupid. (or is there something I don't understand)

Config file is Hearn's stated plan. It's still a bad idea, most people will not touch the defaults. Also, I will believe it when I see it, this is Mike we're talking about.

I agree. I'd prefer if such list was commented out by default. (Though some would say it defeats the purpose of such list in the first place)

[sAt0sHiFanClub]

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

Logical fallacy my ass.

If I want to blacklist you, I will create an ipset 'blacklist' of type hash:ip

Then I ill add your address by

Code:

ipset add blacklist n.n.n.n 

Thats how its done. You cont need Core or XT to do that.  Any node can do that to you right now, running Core 0.11 or any other version.

[brg444]

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

Logical fallacy my ass.

If I want to blacklist you, I will create an ipset 'blacklist' of type hash:ip

Then I ill add your address by

Code:

ipset add blacklist n.n.n.n 

Thats how its done. You cont need Core or XT to do that.  Any node can do that to you right now, running Core 0.11 or any other version.

 

Did you even understand what Carlton wrote? You basically fell into the same logical trap he pointed out.

[sAt0sHiFanClub]

Did you even understand what Carlton wrote? You basically fell into the same logical trap he pointed out.

Philosophy 101 dropouts will be the death of me....

The game is called "Bitcoin XT has code which downloads your IP address to facilitate blacklisting"

Are you playing?

[Carlton Banks]

Do not reply to satoshi fan club if you value a sane argument lol

[sAt0sHiFanClub]

Do not reply to satoshi fan club if you value a sane argument lol

so, how does XT impact the ability of you or others to engage in a blacklist tit-for-tat?

Any impact at all? Other than dealing with possible tor exit nodes? 

[canth]

Wow, this is fucked up and props to turtlehurricane for disclosing this Very important piece of information!

I have not read the whole thread yet, don't hate, I just came here after seeing BayAreaCoin's signature. Had to post to follow along with it in my subscribed threads and so I can catch up and read through what I've missed. Damn, drama on BitcoinTalk is so time consuming with 2 kids sometimes, but I always love to follow along and "be in the know"!

I'll spare you from reading. (if you have time, go ahead though.)

By sowing more disinformation?

In case Bitcoin XT node comes under DDOS attack and connections get filled it will decrease priority of IP-adresses of known TOR exit nodes, thus dropping them in favor of non TOR connections. You can disable this feature if you think it's not a good idea or even use client that doesn't contain it (BIP 101 only).

And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.

The code doesn't compromise your privacy. If you run a node your IP address is visible on the clearnet anyway (how do you think other peers connect to you) and if you are behind a proxy or using TOR this code won't run.

Does a hardcoded list of permissible TOR exit nodes compromise privacy? Can I get a "hell yes"? (link to the XT relevant code, conveniently, is a few posts above)

More importantly it compromises trust as it necessarily introduces a third-party who manages this list.

Yep, now the Tor network can spend your bitcoin. Lookout!

[canth]

That is a positive scenario we are all hoping for, should BIP 101 succeed.  The concern is what % of clients XT will represent in this scenario.  If it is large, then you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.

Based on Hearn's previous proposals, and his complete control over XT, potential features include:

- Automatic updates
- Redlists
- Blacklists
- Whitelists
- Coin tainting

You can insert anything in "Xyz developer might introduce [insert here] in the future. It's a strawman argument and it's a waste of everyone's time discussing what someone might do with FOSS since we can all vote with our feet BEFORE that has any effect. It is not possible to force anyone to run specific client code as long as there are alternatives, which there will be. If you're worried about fungibility then please, let's work on useful things like stealth addresses or built-in mixing or gmaxwell's privacy features based on ring signatures.

I assure you that any sort of coin address lists included in a bitcoin wallet software as you've suggested will not happen or they will be soundly rejected by the community. Devs are going to leave the policing up to the coinbases and chainalysises of the world. There's absolutely no reason to include those features in the wallets - users don't want it, miners don't want it and law enforcement doesn't need it.

For the record, I'd jump ship if any of the above happened.

It isn't completely theoretical when you consider his previous proposals.  He has proposed repeatedly putting central trust-based control into Bitcoin, and he has complete irrevocable control over XT.   Yes, it is possible he won't do all this bad stuff in XT.  But, you have to consider how he could do this BEFORE he does it in order to avoid it, because control is a sneaky thing that can creap in over time.  

Here is a possible plan that could create an irreversible situation, one where you cannot just escape by quitting using XT:

1. Obtains a critical mass of clients.  Let's say 75% of miners are running XT code.
2. Introduces automatic updates for "security reasons".  This will help relieve the pesky decision making progress with upgrades.
3. Introduces ability to identify XT clients.
4. Puts in DoS code based on blacklists and prioritization that are distributed and signed by XT nodes, giving a higher priority to XT connections.  This effectively de-prioritizes non-XT nodes.  Can also easily adds non-XT nodes to lower priority lists (blacklists).  He already put the code into XT, with documented plans to make it utilize more node coordination.  Clearly, the only nodes that are candidates for doing this coordination today are XT nodes, as Core rejected this proposal.  
5. In order to "combat crime", introduces coin tainting (another one of his famous ideas) that can revoke the wealth of those who object, with a negative bias towards non-conforming (non-XT) nodes.

Now, people wake up and realize this is bad stuff.  What happens when you use a non-XT client?  At this point, it is too late to undo.  Technically, you can accomplish all of this without changing the Bitcoin protocol, although this would presumably require different chains and protocols.  With 75% critical mass, however, one could just as easily change the consensus protocol to make it more irreversible.  He's already proved he is willing to do that.  

Yes, there is theory here, as we are talking about a possible future.  Yet, given past proposals to add centralized control to Bitcoin, and his completely control over XT, this is not out of the realm of possibility.  The core risk of Mike's previous proposals which he has become known for is the introduction of central control and trust to our decentralized trust-less Bitcoin.  So, the better question is why would he not use XT to implement his vision?

"2. Introduces automatic updates for "security reasons".  This will help relieve the pesky decision making progress with upgrades."

Dude...I stopped reading after this. If any developer were to attempt to introduce auto-updates, it'll get rejected right off the bat.

[kano]

...
You can insert anything in "Xyz developer might introduce [insert here] in the future. It's a strawman argument and it's a waste of everyone's time discussing what someone might do with FOSS since we can all vote with our feet BEFORE that has any effect.
...

Damn couldn't ignore that
https://bugs.gentoo.org/show_bug.cgi?id=524512

Specifically in comment 4 what gentoo bitcoind was doing by default for all who didn't change it:
2014-10-05 11:38:09 ERROR: AcceptToMemoryPool : ignoring transaction                289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice)

Of course the issue being that people run clients without checking in detail what they do, so you can get a large number of people accepting a client change without even asking them.

The issue here being that people are arguing how they want the XT client where it would seem at least some of them have no idea about what "other" changes other than BIP101 they will get ... and why those other changes are in there.

It becomes: yeah if you don't want what the majority are downloading we have the modified non-standard version that you can get ... that isn't what most people are running who download.

[canth]

...
You can insert anything in "Xyz developer might introduce [insert here] in the future. It's a strawman argument and it's a waste of everyone's time discussing what someone might do with FOSS since we can all vote with our feet BEFORE that has any effect.
...

Damn couldn't ignore that
https://bugs.gentoo.org/show_bug.cgi?id=524512

Specifically in comment 4 what gentoo bitcoind was doing by default for all who didn't change it:
2014-10-05 11:38:09 ERROR: AcceptToMemoryPool : ignoring transaction                289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice)

Of course the issue being that people run clients without checking in detail what they do, so you can get a large number of people accepting a client change without even asking them.

The issue here being that people are arguing how they want the XT client where it would seem at least some of them have no idea about what "other" changes other than BIP101 they will get ... and why those other changes are in there.

It becomes: yeah if you don't want what the majority are downloading we have the modified non-standard version that you can get ... that isn't what most people are running who download.

Heh...I haven't forgotten the luke-jr gentoo update. With that said, do you really think that Hearn and/or Gavin are going to quietly try to introduce auto-updates, blacklists or anything else? Even if they managed to pull it off and a few early upgraders got snared, it would be the end of their reputations. Call me just not that concerned.

[erik777]

...
You can insert anything in "Xyz developer might introduce [insert here] in the future. It's a strawman argument and it's a waste of everyone's time discussing what someone might do with FOSS since we can all vote with our feet BEFORE that has any effect.
...

Damn couldn't ignore that
https://bugs.gentoo.org/show_bug.cgi?id=524512

Specifically in comment 4 what gentoo bitcoind was doing by default for all who didn't change it:
2014-10-05 11:38:09 ERROR: AcceptToMemoryPool : ignoring transaction                289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice)

Of course the issue being that people run clients without checking in detail what they do, so you can get a large number of people accepting a client change without even asking them.

The issue here being that people are arguing how they want the XT client where it would seem at least some of them have no idea about what "other" changes other than BIP101 they will get ... and why those other changes are in there.

It becomes: yeah if you don't want what the majority are downloading we have the modified non-standard version that you can get ... that isn't what most people are running who download.

Heh...I haven't forgotten the luke-jr gentoo update. With that said, do you really think that Hearn and/or Gavin are going to quietly try to introduce auto-updates, blacklists or anything else? Even if they managed to pull it off and a few early upgraders got snared, it would be the end of their reputations. Call me just not that concerned.

Hearn already introduced blacklists -- first to Core, which was rejected, then to XT, which is included in the download since he is the "benevolent dictator" of XT.  Hence the topic.