Topic: ... - page 29. (Read 61015 times)

Thanks!  

It would be a pointless way to do it - if it was that urgent to update exit nodes then you would just use a relay service. That way 'they' (as in gubmint) could only track the relay.

Yes yes, you get candy!

Meanwhile a new commit will come up to "improve anti-ddos" which will move that stuff directly in the bitcoin binary. Gavin would ACK Mike's pull request and it's done!

You do know that is a python script, run at compile time to dynamically generate the list from tor? Unless you are recompiling bitcoin binaries ( on your live server!!) every time you start your node, then this is not an issue. If tor does indeed log ip addresses ( which makes the whole thing pointless anyway) then they are only logging the address of the machine that compiled the code. In most (intelligent) cases that will not be the one running the node. In most cases you will be downloading binaries.

Do I get my candy now?

Andreas Antonopoulous on blockchain size:

That conversation begins at the 30 minute and 37 second mark:  https://www.youtube.com/watch?v=3jqpKEHYGE0

Probably someone is shouting in the phone:
"Bring in more trolls! Now! They found out the candy!"

The following is so darn hard to understand, I'm so confused!  

Thank you, I did miss that part yeah. Here it is:
Source: https://github.com/bitcoinxt/bitcoinxt/blob/master/src/main.cpp
Lines: 223 and 224

Just because it isn't in the linked commit, doesn't mean it doesn't exist. It exists in the master branch and the latest release.

What? Are you talking about this ?


Look closely, do you see there is anything missing in yours?

Do you how cvs diff works?

Nobody is denying anything. Its been explained. If you cant grasp what it does and how it works then nobody is forcing you to do anything.

Do you need to call someone a shill troll for merely pointing that out? Or is there really only one side to this debate 

It shouldn't be political, but it clearly is. But what it should never be is personal. Its software - we will work it out.

I am amased of the army of XT shill trolls in this thread trying to deny the obvious.  . But this IP/Tor blacklisting and connecting to torproject with "Bitcoin XT" user agent stinks so bad that even a 100 troll army can't cover it up.   

Anyway, the block size increase is not so urgently required as the XT supporters make you think. We can go on for a couple of years until consensus is reached in Bitcoin Core. But this is a debate for another thread.

OMG urgent problem! here is the solution! don't mind the privacy killing code, it's for your own protection and you can disable it if you want 

It sure was. >How one person can so misinterpret a few lines of code so badly is beyond most. Especially when he freely admits he doesn't understand the code and how tor peers work. Yet when propeller heads from both sides explain it, he persists.

The code isn't hard to find at all and clearly exist, so please stop saying that it doesn't.

Source: https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23
File: src/ipgroups.h
Lines: 5 to 24.

It can be found in the master and the latest release of Bitcoin XT:
https://github.com/bitcoinxt/bitcoinxt/blob/master/src/ipgroups.h
https://github.com/bitcoinxt/bitcoinxt/blob/0.11A/src/ipgroups.h

what's the real problem in upgrading core with a bigger blocksize? i have not seen any other counter argument for this, why instead of making a new "alternative client", we simply go ahead and push the block size on core, it sounds so simple and less troublesome

and it would have saved us all this mess and the crash of bitcoin which was holding really nice until this shit has come out...

Thanks for this...it is a definite eye-opener!

look like you have lots to read about

Have fun

This needs more exposure! I don't understand why the Core team won't just double size to 2mb and end this nonsense. In a few years time, we can re-visit the issue and possibly bump it up to 4mb if there are still no solutions. The devs are acting like babies.

Very true, and our former friend, Theymos also supported this idea.

They put tor exit nodes on a list.  That list does not function as a black list until or unless a DoS attack starts coming from tor exit nodes and it gets bad enough that the Tor-Exit-Nodes-List gets banned.

If someone is carrying out a DoS attack via Tor, it will disconnect all Tor users rather than only disconnecting the ones performing the attack. 

This is because the people implementing it have no desire to break Tor.  If there was a serious effort to ban only the Tor users perpetrating the DoS attack, that would require breaking Tor anonymity to figure out what users those were.  If you don't make any attempt to break Tor anonymity (and they don't) then you have to treat all Tor connections as equal.

I'm annoyed that they tried to do this at the same time as the block size issue - the block size change would have gone through without a problem if left to adoption rather than blockstream shills screaming about it.  It was plain bad judgment to do anything else at the same time though, because now the block stream shills get to scream FUD about something else in order to fight the block size increase.  I guarantee they wouldn't give a crap about it if the block size increase had already gone through, bitcoin had been made scalable without them, and their fucking expensive business plan which they're trying to build by increasing transaction expenses for everybody, was already in the toilet.

Bitcoin exists for purposes beyond making a profit  for Blockstream. 

ummm , I think he's disgraced himself by his actions. When the puppy pees on the rug he needs to be put outside and think about what he has done before he can rejoin the circle.

https://www.youtube.com/watch?v=QHJGoZpFeM8