...

[canth]

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

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

Blacklists that aren't used except when inbound connections are already full - very effective tools at blocking people from using Bitcoin. Yes, you're right, I can see it - next thing Hearn will want to restrict certain bitcoin addresses from moving 666.666 BTC. 

C'mon, there are other changes in XT that you haven't managed to mislabel and create misinformation with. Let me help you out:

BIP101 8GB blocks - CIA Google sponsored mining and node centralization. Google-coin, run exclusively in Google datacneters, here we come. In only 20 years! Invest in GOOG now, while you still can.
Double spend relaying - every double spend trx relayed causes more load on the P2P network. The sooner we need 10gbit+ to run an SPV wallet, the sooner Google takes over.
BIP64 getutxos - Not only does this allow for more P2P traffic, it allows for Hearn's evil FOSS lighthouse takeover of crowdsourcing channeled through the SEC. Ver are your investor papers?!
DNS seed - unlike Core which connects to Good DNS seeds, XT connects to Evil DNS seeds which report your wallet balance and SSN to the IRS the first time every time you connect, in plain text.

Since Hearn's already a dictator, we have no choice but to succumb to his evil machinations, so it's pretty much too late. I for one welcome my new Bitcoin overlords...as should you all.

[1715132907]

1715132907

[1715132907]

1715132907

[DarkHyudrA]

I don't know why there still so much war against XT.
XT is a falied project from beginning, even the minted blocks almost have no more BIP101 acceptance, the XT fork will never happen.

[canth]

I don't know why there still so much war against XT.
XT is a falied project from beginning, even the minted blocks almost have no more BIP101 acceptance, the XT fork will never happen.

No, Hearn is a dictator and says you must run XT. BIP101 will be introduced as a new law in Congress in 2016, applying globally. Yes, even places like Antartica and the Moon.

PS. I also heard Hearn's behind fluoridation.

[tvbcof]

I don't know why there still so much war against XT.
XT is a falied project from beginning, even the minted blocks almost have no more BIP101 acceptance, the XT fork will never happen.

No, Hearn is a dictator and says you must run XT. BIP101 will be introduced as a new law in Congress in 2016, applying globally. Yes, even places like Antartica and the Moon.

PS. I also heard Hearn's behind fluoridation.

One cannot help but notice the he wasn't in the twin towers.  Hmmm...makes a guy wonder don't it?

[wxa7115]

I don't know why there still so much war against XT.
XT is a falied project from beginning, even the minted blocks almost have no more BIP101 acceptance, the XT fork will never happen.

No, Hearn is a dictator and says you must run XT. BIP101 will be introduced as a new law in Congress in 2016, applying globally. Yes, even places like Antartica and the Moon.

PS. I also heard Hearn's behind fluoridation.

LOL, I suppose that the bill will apply in heaven, hell, the rest of the universe, other universes and finally other dimensions.

[miragecash]

Using google translate, I posted in the China section. It seems to have the intended effect. All the miners in the China section are for Bitcoin core, not XT.

BTW, google translate seems to make gibberish in Chinese if you use long sentences. However, if you keep the sentences to small phrases, as in Arnold Schwartzeneggar in "Terminator" short, google translate seems to do o.k.

Yeah, all the linguists I've spoken with say that in the future, everyone will be speaking either English or Chinese because most internet traffic is in these 2 languages. They all wistfully hope for Esperanto, though.

I don't know if cryptocurrency will become widely adopted or not. I mean, it might be like Linux or Esperanto, great ideas but nobody wants to use them. However, I am betting that it will be as popular as email in 20 to 30 years. Which cryptocurrency? Litecoin? Bitcoin? Monero? Or something else not yet released into the wild? Who knows? The future will be very interesting, indeed.

[Carlton Banks]

Using google translate, I posted in the China section. It seems to have the intended effect. All the miners in the China section are for Bitcoin core, not XT.

BTW, google translate seems to make gibberish in Chinese if you use long sentences. However, if you keep the sentences to small phrases, as in Arnold Schwartzeneggar in "Terminator" short, google translate seems to do o.k.

This is pretty much the case with all languages BTW, although I can imagine that languages with very different grammar and colloquialisms to each other will produce worse results.

A good way to test (no doubt you tried this) is to translate from, say, English to Chinese, then trnsalate that output from Chines back into English! If it comes out too strange, it's possible you need to shorten that sentence.

I don't know if cryptocurrency will become widely adopted or not. I mean, it might be like Linux or Esperanto, great ideas but nobody wants to use them. However, I am betting that it will be as popular as email in 20 to 30 years. Which cryptocurrency? Litecoin? Bitcoin? Monero? Or something else not yet released into the wild? Who knows? The future will be very interesting, indeed.

With the direction the Windows and OS X are heading in these days, I predict that Linux's failure on the Home PC may be due for a turn around. At least, Windows and OS X are in for a turnaround, and something has to pick up the slack.

Remember also that the most popular mobile phone OS is Linux, so it's more prevalent than you might have thought.

[miragecash]

57 percent of Bitcon mining is done in China. The fact that nobody (but me) bothered to repost this OP's post in the Chinese section is crazy!

Reference: http://www.businessinsider.com/bitcoin-pools-miners-ranked-2015-7?r=UK&IR=T

[SirChiko]

I'm combing through the code and it's not looking good.





Basically they will disconnect you if your address has 'low priority', which might hurt new addresses. If you have a negative priority score that means you're an attacker according to them, and you are disconnected.

Also mapping the tor network, lots of code aside from this to break through the anonymity of TOR.



These changes are massive and BitcoinXT has not mentioned them at all, clearly the block size debate is a distraction.

That's fucked up and i hope they won't get 51%+ of bitcoin users on their side..they would have to be really uneducsted about changes...it won't be just improvement of performance but it will be something worse or same as centralization.
Atleast in my eyes.

[Swimmer63]

I am not a developer, but I am told by reliable sources that Core uses, or it's proposed to have very similar spam and prioritization coding.  I think some kind of protection will be a necessary evil.  Of course you can run your own without it if you choose.

[SirChiko]

I am not a developer, but I am told by reliable sources that Core uses, or it's proposed to have very similar spam and prioritization coding.  I think some kind of protection will be a necessary evil.  Of course you can run your own without it if you choose.

But i don't think it will log your IP or try to block tor connections. Just maybe some kind of anti attack filter but not like this.
Also see other critised "addons" that xt developers want to put into code.
It just changes whole bitcoin as it is..and i don't think that it would be in any positive way for our currency.

[erik777]

I am not a developer, but I am told by reliable sources that Core uses, or it's proposed to have very similar spam and prioritization coding.  I think some kind of protection will be a necessary evil.  Of course you can run your own without it if you choose.

The difference that we object to is the use of a "trusted" third party to prioritize.  Core does not rely on an external list, nor does it inject a had coded one. 

[Cryddit]

Those changes (special treatment for Tor exit nodes, downloading a list) haven't been a point of contention for developers as far as I know.  It would be silly to assume they're not going into the next revision of core. 

[brg444]

Those changes (special treatment for Tor exit nodes, downloading a list) haven't been a point of contention for developers as far as I know.  It would be silly to assume they're not going into the next revision of core. 

 

This exact change was made into a pull request to Core by Mike and was generally opposed by most of the other developers (except maybe Gavin of course...)

[canth]

Those changes (special treatment for Tor exit nodes, downloading a list) haven't been a point of contention for developers as far as I know.  It would be silly to assume they're not going into the next revision of core. 

 

This exact change was made into a pull request to Core by Mike and was generally opposed by most of the other developers (except maybe Gavin of course...)

It was supported, except for the inclusion of IP addresses in the Core client which was considered 'centralization', which on the threats of centralization is pretty damn small. If we really want to focus on centralization problems, here's the biggest target:



Anyone that talks about centralization threats and isn't working on ways to make small pool mining more competitive is really sticking their head in the sand. We are a few police raids at 3-4 chinese mining farms away from censorship, double spend hell or just a plain 'orphan every non-controlled block' DoS attack.

[brg444]

Those changes (special treatment for Tor exit nodes, downloading a list) haven't been a point of contention for developers as far as I know.  It would be silly to assume they're not going into the next revision of core. 

 

This exact change was made into a pull request to Core by Mike and was generally opposed by most of the other developers (except maybe Gavin of course...)

It was supported, except for the inclusion of IP addresses in the Core client which was considered 'centralization', which on the threats of centralization is pretty damn small. If we really want to focus on centralization problems, here's the biggest target:

Anyone that talks about centralization threats and isn't working on ways to make small pool mining more competitive is really sticking their head in the sand. We are a few police raids at 3-4 chinese mining farms away from censorship, double spend hell or just a plain 'orphan every non-controlled block' DoS attack.

Hmm no I'm quite certain it received a majority of NACK given it is absolutely useless against spam and I believe the word you're looking for is not centralization but "trust" as in: a list is necessarily maintained by a third-party, something Bitcoin has historically avoided at all cost and for very good reasons

[canth]

Those changes (special treatment for Tor exit nodes, downloading a list) haven't been a point of contention for developers as far as I know.  It would be silly to assume they're not going into the next revision of core. 

 

This exact change was made into a pull request to Core by Mike and was generally opposed by most of the other developers (except maybe Gavin of course...)

It was supported, except for the inclusion of IP addresses in the Core client which was considered 'centralization', which on the threats of centralization is pretty damn small. If we really want to focus on centralization problems, here's the biggest target:

Anyone that talks about centralization threats and isn't working on ways to make small pool mining more competitive is really sticking their head in the sand. We are a few police raids at 3-4 chinese mining farms away from censorship, double spend hell or just a plain 'orphan every non-controlled block' DoS attack.

Hmm no I'm quite certain it received a majority of NACK given it is absolutely useless against spam and I believe the word you're looking for is not centralization but "trust" as in: a list is necessarily maintained by a third-party, something Bitcoin has historically avoided at all cost and for very good reasons

Honestly, I wasn't around during the discussions so I'm not completely familiar with why they were voted down.

Regarding trust, a lot of bitcoiners seem to be very black and white about their risk modeling. I agree that we don't want to erode decentralization or rely upon centralized 3rd parties, but actually thinking about the tradeoffs is better than gut rejections.

Let's ask the question:
What happens if the Tor Project gets compromised and the IP list is flooded with known node IP addresses?

- If your node is behind a proxy, nothing - anti-ddos is auto disabled
- If your node is manually turned off, nothing - anti-ddos is disabled
- If your node is not under attack, nothing - anti-ddos doesn't activate until incoming connections are full

- If your node has all inbound connections full (presumably under attack), then you will start dropping connections based upon the "Tor Project's compromised lists". You'll still have your outbound connections which won't be affected but some known nodes won't be able to connect to your node.

Seems like a pretty mild issue to me.

[poeEDgar]

Honestly, I wasn't around during the discussions so I'm not completely familiar with why they were voted down.

Regarding trust, a lot of bitcoiners seem to be very black and white about their risk modeling. I agree that we don't want to erode decentralization or rely upon centralized 3rd parties, but actually thinking about the tradeoffs is better than gut rejections.

Let's ask the question:
What happens if the Tor Project gets compromised and the IP list is flooded with known node IP addresses?

- If your node is behind a proxy, nothing - anti-ddos is auto disabled
- If your node is manually turned off, nothing - anti-ddos is disabled
- If your node is not under attack, nothing - anti-ddos doesn't activate until incoming connections are full

- If your node has all inbound connections full (presumably under attack), then you will start dropping connections based upon the "Tor Project's compromised lists". You'll still have your outbound connections which won't be affected but some known nodes won't be able to connect to your node.

Seems like a pretty mild issue to me.

Let's take a look at this from another angle.

Does a node need a trusted list to tell it when an IP address is maliciously attacking it? No. It can deprioritize access from that IP address.

So what's the point of the list? Before we get to trusted vs. trustless -- why does this feature even exist? It serves no purpose.

[turvarya]

Honestly, I wasn't around during the discussions so I'm not completely familiar with why they were voted down.

Regarding trust, a lot of bitcoiners seem to be very black and white about their risk modeling. I agree that we don't want to erode decentralization or rely upon centralized 3rd parties, but actually thinking about the tradeoffs is better than gut rejections.

Let's ask the question:
What happens if the Tor Project gets compromised and the IP list is flooded with known node IP addresses?

- If your node is behind a proxy, nothing - anti-ddos is auto disabled
- If your node is manually turned off, nothing - anti-ddos is disabled
- If your node is not under attack, nothing - anti-ddos doesn't activate until incoming connections are full

- If your node has all inbound connections full (presumably under attack), then you will start dropping connections based upon the "Tor Project's compromised lists". You'll still have your outbound connections which won't be affected but some known nodes won't be able to connect to your node.

Seems like a pretty mild issue to me.

Let's take a look at this from another angle.

Does a node need a trusted list to tell it when an IP address is maliciously attacking it? No. It can deprioritize access from that IP address.

So what's the point of the list? Before we get to trusted vs. trustless -- why does this feature even exist? It serves no purpose.

What does "maliciously attacking" mean in that concrete context?
And if it is so easy to determine that, why has nobody done it yet?

[canth]

Honestly, I wasn't around during the discussions so I'm not completely familiar with why they were voted down.

Regarding trust, a lot of bitcoiners seem to be very black and white about their risk modeling. I agree that we don't want to erode decentralization or rely upon centralized 3rd parties, but actually thinking about the tradeoffs is better than gut rejections.

Let's ask the question:
What happens if the Tor Project gets compromised and the IP list is flooded with known node IP addresses?

- If your node is behind a proxy, nothing - anti-ddos is auto disabled
- If your node is manually turned off, nothing - anti-ddos is disabled
- If your node is not under attack, nothing - anti-ddos doesn't activate until incoming connections are full

- If your node has all inbound connections full (presumably under attack), then you will start dropping connections based upon the "Tor Project's compromised lists". You'll still have your outbound connections which won't be affected but some known nodes won't be able to connect to your node.

Seems like a pretty mild issue to me.

Let's take a look at this from another angle.

Does a node need a trusted list to tell it when an IP address is maliciously attacking it? No. It can deprioritize access from that IP address.

So what's the point of the list? Before we get to trusted vs. trustless -- why does this feature even exist? It serves no purpose.

The feature isn't about dealing with a single IP address attack - rather it's what to do when you have full incoming connections and are 'attacked' by multiple sources. I'll turn it around - if you have full inbound connections, what should the policy be? Should your node not accept any new incoming connections? (that's the goal of the attack) Or if you need to drop connections, which should be dropped first? If you were an attacker, would you attack on clearnet or via Tor and proxy? There is a rationale that went into this feature - it wasn't just for shits and giggles.

The silly thing is that for most users, most of the time it'll never come into play. It's a non-issue.