Topic: ... - page 7. (Read 61013 times)

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

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.

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.

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.

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)

See above.

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

By sowing more disinformation?


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.


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)

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)

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://bitcointalksearch.org/topic/m.12284427

This is another nail in coffin of Bitcoin XT, its anti privacy and hostility measures have reached a point of no return for me. So I suppose the only thing left is to fork and see how it goes from there

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

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?

Let it be known that I do not like Mike and Gavin.  Signed: ~tvbcof

I'm not talking about on a personal level since I don't know them.  Given their attitudes about certain things as reflected in their actions and activities, I probably would not like them on a variety of personal levels either though.

Just for completeness, here's Peter's reply to Mike

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010497.html

It's amazing - Bitcoiners out of one side of their mouth talk about decentralization and freedom. On the otherside, they really seem to not like it so much when there's decentralization on the decision and development process. Doesn't that sound strange to you? It's fine that you don't like Hearn or Gavin, but why not just say that? It can't be that you really think that Bitcoin is the Blockstream Company or nothing, do you?

So let me get this straight, you think that the Tor project is tracking bitcoin users since that's where the IPs are downloaded from? Shh...don't tell anyone but Bitcoin Core has a tracking feature where the first time you launch it, it tracks your IP via the DNS seed too. Better not run that either. Damn centralization! /

And as far as the IP address prioritization goes, let me ask you this. In the event that you run a node and all incoming connections are full - how do you think that connections should be prioritized? Should new connections be ignored? Should you drop some Tor IP address to make room for other connections? Hearn came up with a prioritization that you don't like - fine. Disable it or come up with something better or run Bitcoin Core or run only-bigblocks. Lots of options and yet you choose to spread misinformation.

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.

The BIP66 voting was inept too.  It was the ineptitude of the Core devs, not dishonest miners, that caused the two "forks of July" (6-block and 3-block long, respectively) and required broadcasting to all clients the embarrassing alert "everybody had better wait for 30 confirmations for a while".

The BIP100 voting scheme is a joke.

I think that blcokchain voting in general is a stupid idea, but the 75% of the BIP101 voting is not bad.  Any brat can set up NotXT nodes to falsify the node statistics; miners, however, will not want to play games with their revenue.  If they are against BIP101, their interest is to vote against it, to prevent the 75% trigger to happen. Why would they want to trigger a messy fork and then have it collapse?  That is the sort of puerile "cut the nose to spite the face" reprisal that only a Blockstream worker would find amusing...


If Adam had not been born, BitcoinCore would probably have lifted the block size limit years ago...

The idea of patching a client was something I thought of out of thin air and suggested in the last round of wars near the begining of the year as I recall.

The voting implantation was so laughably simplistic that the attack practically suggested itself.  If that is the design quality of XT under Hearn's benevolent dictatorship, heaven state sponsored judicial system help you guys.

If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.

The war would not have happened if Adam had not labored so hard to create it.

The NotXT fork and the DDoS attacks on XT nodes may not have been his idea, but
he does seem to think that they were "well done".

EDIT:  There are other options for a higher block limit than full BitcoinXT --
such as a patched BitcoinCore, BitcoinXT with only BIP101, or simply editing
the MAX_BLOCK_SIZE line to raise the limit on a fixed date.  Raising the limit to 8 MB
does not present any demonstrable risk, but avoids congestion and
reduces risks and consequences of spam attacks.  Adam did not start the war
for technican reasons, but only to protect Blockstream's  power grip on
the protocol.