miragecash
|
|
August 30, 2015, 07:40:25 PM |
|
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#msg12284427Thanks 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.htmlBitcoin 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
|
|
|
|
uxgpf
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 30, 2015, 07:45:02 PM Last edit: August 30, 2015, 08:06:20 PM by 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
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
August 30, 2015, 08:01:15 PM |
|
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)
|
Vires in numeris
|
|
|
brg444
|
|
August 30, 2015, 08:45:04 PM |
|
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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
uxgpf
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 30, 2015, 08:46:44 PM |
|
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
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
August 30, 2015, 08:58:10 PM |
|
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.
|
Vires in numeris
|
|
|
brg444
|
|
August 30, 2015, 09:01:36 PM |
|
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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
uxgpf
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 30, 2015, 09:02:23 PM Last edit: August 30, 2015, 09:15:57 PM by 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
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
August 30, 2015, 09:06:20 PM |
|
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.
|
Vires in numeris
|
|
|
uxgpf
Newbie
Offline
Activity: 42
Merit: 0
|
|
August 30, 2015, 09:17:29 PM |
|
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
|
|
August 30, 2015, 09:58:13 PM |
|
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 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.
|
We must make money worse as a commodity if we wish to make it better as a medium of exchange
|
|
|
brg444
|
|
August 30, 2015, 10:01:26 PM |
|
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 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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
sAt0sHiFanClub
|
|
August 30, 2015, 10:11:51 PM |
|
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?
|
We must make money worse as a commodity if we wish to make it better as a medium of exchange
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
August 30, 2015, 10:19:14 PM |
|
Do not reply to satoshi fan club if you value a sane argument lol
|
Vires in numeris
|
|
|
sAt0sHiFanClub
|
|
August 30, 2015, 10:25:00 PM |
|
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?
|
We must make money worse as a commodity if we wish to make it better as a medium of exchange
|
|
|
canth
Legendary
Offline
Activity: 1442
Merit: 1001
|
|
August 31, 2015, 12:27:22 AM |
|
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
Legendary
Offline
Activity: 1442
Merit: 1001
|
|
August 31, 2015, 12:29:03 AM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 31, 2015, 12:50:38 AM |
|
... 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=524512Specifically 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
Legendary
Offline
Activity: 1442
Merit: 1001
|
|
August 31, 2015, 01:53:24 AM |
|
... 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=524512Specifically 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
Sr. Member
Offline
Activity: 504
Merit: 250
Earn with impressio.io
|
|
August 31, 2015, 02:47:50 AM |
|
... 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=524512Specifically 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.
|
|
|
|
|