The Anti-XTers Are Harming Bitcoin

[cogabonito]

what do sync issues have to do with block size?

you obviously have no idea what you are talking about...

and well... its easy to calculate how "much spam attack" we can get with 8mb. just imagine how expansive a 1tb drive is today and how long it takes to get filled... really a big problem

What? Bigger blocks than needed means blockchain open for spam attacks. It's obviously related to sync issues, like we had in early August. You obviously have no idea what we have faced this summer. If your holiday is over, read some Bitcoin news.

[BTCat]

XT fails because if every IP using it is blacklisted, it would be dead.
XT is like terrorism against Bitcoin and the community.

[Zarathustra]

XT fails because if every IP using it is blacklisted, it would be dead.
XT is like terrorism against Bitcoin and the community.

Educate yourself.

https://bitcointalk.org/index.php?topic=1156489.msg12221920#msg12221920

[Klestin]

XT fails because if every IP using it is blacklisted, it would be dead.
XT is like terrorism against Bitcoin and the community.

There is no blacklisting.  You've been lied to.  Go read the code directly, or have someone you trust check it for you. 

Here's the actual reality:

- All nodes have connection limits - they can't connect to each and every other node in the world. The default limit for popular nodes is 125.
- That limit is normally only reached if someone out there is trying to attack you with a denial of service attack. My node runs at about 30 connections, all day, every day.
- At present, when the limit is reached, no new nodes can connect. If you're filled with attackers, that's bad for Bitcoin.

All of the above is the way it works in Core, right now.  Here's what XT adds, intended to improve this situation:

- XT has a list of TOR exit nodes, and can read an updated list of TOR exit nodes.
- ONLY when the connection limit is reached, instead of blindly blocking new connections, XT will select a TOR exit node to disconnect to allow the new plain connection.
- When the DOS attack is over, those connections will once again be accepted.

[alani123]

There's a lot of people that stand behind the idea of larger bitcoin blocks but would rather avoid Mike Hearn's and Gavin Andresen's implementation.

The Chinese pools in specific, support 8Mb blocks but don't trust Mike hearn. Mike has made multiple statements that have put him in a bad position in their eyes. Among other things, he implied that bitcoin XT could start ignoring the longest chain to avoid the veto od the Chinese miners. "We'll have to carry on without them" in his own words.

[zimmah]

There's a lot of people that stand behind the idea of larger bitcoin blocks but would rather avoid Mike Hearn's and Gavin Andresen's implementation.

The Chinese pools in specific, support 8Mb blocks but don't trust Mike hearn. Mike has made multiple statements that have put him in a bad position in their eyes. Among other things, he implied that bitcoin XT could start ignoring the longest chain to avoid the veto od the Chinese miners. "We'll have to carry on without them" in his own words.

Yeah I don't get this whole XT debate. I want larger blocks as well, but I'm nkt sure I want XT. I'd prefer it if we could just implement larger blocks in core and be done with it, this whole discussion is threatening Bitcoin.

[Muhammed Zakir]

-snip-
- XT has a list of TOR exit nodes, and can read an updated list of TOR exit nodes.
- ONLY when the connection limit is reached, instead of blindly blocking new connections, XT will select a TOR exit node to disconnect to allow the new plain connection.
- When the DOS attack is over, those connections will once again be accepted.

Both automatic download of TOR exit nodes and "IP prioritizing" are bad IMHO. They do more harm than good.

[TheAnalogKid]

There's a lot of people that stand behind the idea of larger bitcoin blocks but would rather avoid Mike Hearn's and Gavin Andresen's implementation.

The Chinese pools in specific, support 8Mb blocks but don't trust Mike hearn. Mike has made multiple statements that have put him in a bad position in their eyes. Among other things, he implied that bitcoin XT could start ignoring the longest chain to avoid the veto od the Chinese miners. "We'll have to carry on without them" in his own words.

Yeah I don't get this whole XT debate. I want larger blocks as well, but I'm nkt sure I want XT. I'd prefer it if we could just implement larger blocks in core and be done with it, this whole discussion is threatening Bitcoin.

Then put your voice behind BIP100:

http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

This extends the block size in core, making it a dynamic variable that can be voted on by the miners and pools to adjust up and down as market pressures dictate.  It's the most solid proposal I've seen to date, and it addresses the core issue at hand, without all the other extra stuff within BIP101/XT that is making it distasteful.

[Klestin]

-snip-
- XT has a list of TOR exit nodes, and can read an updated list of TOR exit nodes.
- ONLY when the connection limit is reached, instead of blindly blocking new connections, XT will select a TOR exit node to disconnect to allow the new plain connection.
- When the DOS attack is over, those connections will once again be accepted.

Both automatic download of TOR exit nodes and "IP prioritizing" are bad IMHO. They do more harm than good.

During an attack, when your connection limit is reached, someone is getting blocked.  You can either block a new clearnet connection, or you can let it in and disconnect a TOR exit node.

You can always disable this behavior via the -disableiprio option if you like.

[Carlton Banks]

-snip-
- XT has a list of TOR exit nodes, and can read an updated list of TOR exit nodes.
- ONLY when the connection limit is reached, instead of blindly blocking new connections, XT will select a TOR exit node to disconnect to allow the new plain connection.
- When the DOS attack is over, those connections will once again be accepted.

Both automatic download of TOR exit nodes and "IP prioritizing" are bad IMHO. They do more harm than good.

During an attack, when your connection limit is reached, someone is getting blocked.  You can either block a new clearnet connection, or you can let it in and disconnect a TOR exit node.

You can always disable this behavior via the -disableiprio option if you like.

That's misleading.

The option you refer to prevents people using Tor to DOS attack your node. But it cannot prevent your node being blocked from connecting to the XT network by others who do not disable the feature.

This is not a problem on the Bitcoin network.

[Klestin]

That's misleading.

The option you refer to prevents people using Tor to DOS attack your node. But it cannot prevent your node being blocked from connecting to the XT network by others who do not disable the feature.

This is not a problem on the Bitcoin network.

It isn't misleading at all. If you don't like that DOS protection, don't run it.  Your position implies that you want to deny others the option to us that DOS protection. 

[Carlton Banks]

That's misleading.

The option you refer to prevents people using Tor to DOS attack your node. But it cannot prevent your node being blocked from connecting to the XT network by others who do not disable the feature.

This is not a problem on the Bitcoin network.

It isn't misleading at all. If you don't like that DOS protection, don't run it.  Your position implies that you want to deny others the option to us that DOS protection. 

I'm sure there are better ways to protect from DOS attacks that cannot be so easily subverted against their advertised purpose. Your position implies you don't mind if crude DOS protection sacrifices reliable connection to the Tor network. You're wrong.

[Zarathustra]

That's misleading.

The option you refer to prevents people using Tor to DOS attack your node. But it cannot prevent your node being blocked from connecting to the XT network by others who do not disable the feature.

This is not a problem on the Bitcoin network.

It isn't misleading at all. If you don't like that DOS protection, don't run it.  Your position implies that you want to deny others the option to us that DOS protection.  

I'm sure there are better ways to ...

Yes, you are always 'sure that there are better ways' for everything. That's your discussion style. It's unmasked alreaday.

[YarkoL]

Imagine a future where we have all sorts of competing implementations with purposely-deceptive names:

1. "Bitcoin Core"  [implies that it's the core of Bitcoin]

2. "Standard Bitcoin"  [to imply that it's that standard version]

3. "Real Bitcoin"  [to imply that it's the "real" bitcoin]

4. "Super Fun Time Bitcoin" [just for the lolz]

Every one of them could spinoff 
other competitors. Problem solved