Quote from: madjules007 on August 20, 2015, 12:12:39 AM

Quote from: Lucko on August 19, 2015, 11:47:32 PM

Quote from: madjules007 on August 19, 2015, 11:42:28 PM

Quote from: Lucko on August 19, 2015, 11:31:41 PM

Quote from: Greendragon on August 19, 2015, 11:23:15 PM

Quote

So you cant give us any part of the code to support your statement? Yup you're not a programmer just a dumb ass who got told what it is.

Can you bro?

None can. You cant prove an negative only positive. The only way would be to exclude every part of a code... So copy pase the code? But that doesn't help right?

This issue is being used as a red herring. Does no one have a problem with the idea that XT is supposed to address the block size issue, but so much code that is irrelevant to that is being pushed out? We can argue all day about one detail or another -- but can you XT supporters explain why the hell it's all there? And why it's being presented solely as a solution to the block size debate?

Strip it down and stop trying to force other changes down our throats.....

Quote

Let's not get bogged down by the details. What the hell are these pages and pages of code that have absolutely fuck all to do with block size? And why is it being pushed then solely as a fix for the block size issue?

Not really. XT is compatible with QT now. And it will be with XT and QT+BIP101. You can also run QT+BIP101 if you are worried... And there is a QT made by Mike if you don't like XT. Only BIP101.

That's not really addressing what I said. Yes, I run QT. I'm not really concerned about that and won't change unless forced. I'm concerned about a primarily political push to drive the community to adopt a new protocol under the pretense of a need for larger blocks, but that a) includes other protocol changes (relaying double spends, querying the UTXO set, DNS seed changes, others like the TOR deprioritization code which I still don't quite understand, etc) that aren't widely consented to and b) that the 8MB/double every two years limit does not adequately consider the stake that [largely Chinese] miners with low bandwidth have in the protocol.

Quote from: turtlehurricane on August 19, 2015, 11:58:59 PM

This is for banning IPs, that's not up for debate. The debate is whether this is just for DoS offenders or if it can be used to blacklist anyone.

I think this is a fair assessment. Arguing over "banning" vs. "deprioritizing" is playing with semantics. The question I have, as someone who is not particularly technical, is whether there are implications here that go further than simply "deprioritizing TOR nodes that are actively DOS attacking" and haven't really seen an adequate answer.

It is for everyone on TOR whan TOR is DOSing... Just read the code. When you get 125 connections on a core it will start drooping TOR connections if any unTOR connection will come in. So even when DOSed it will not drop all... nonTOR is prioritized because there are Exchanges and Wallets and Payment processors there...

Need bigger blocks... Well do we need IPv6... Wouldn't it be grate if we done that way back... It cost so much more now then it would...

DNS seed changes
I really don't see a problem removing one that isn't working and adding himself...

querying the UTXO set
Did read what XT says about it but did not have time to do more research. If I don't like it I can still use QT+BIP101. But you can tell me the issue...

relaying double spends
Did read what XT says about it but did not have time to do more research. If I don't like it I can still use QT+BIP101. But you can tell me the issue...