Pages:
Author

Topic: ... - page 5. (Read 61003 times)

legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
September 04, 2015, 07:25:28 PM


Cartoons and graphics sometimes say more than thousand words.
Today I found the truth table in the cyberspace. Wink



How's that "truth" of community support for BIP101 working out for you?

Oh wait, not a single BIP101 block was ever mined.  After the tremendous noise/drama/chaos over XT, all Team Gavin got were some spoofed blocks (and cartoons).

Meanwhile most of the hashing power supports the unfinished BIP100 as a giant FUCK YOU to BIP101.   Cool
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
September 04, 2015, 07:16:00 PM

It was one of the devs (Peter Todd maybe) who wrote on reddit that Sidechains are not a solution for scaling.  For some time now, I haven't seen them claim that they are.  Sidechains are still said to be ways to test all sorts of alternative ideas without endangering Bitcoin itself.

Last I heard, Todd has nothing to do with Blockstream other than he throws rocks at them as is his nature.  Philosophically, I like his treechains idea better but I see it as at best impractical and maybe impossible.  As I see it, what I had in 2011 called 'subordinate chains' have a wide and diverse set of advantages.  You've quasi-listed a few.

As for myself, I have read the Oct/2014 whitepaper with some care,  It mentions many examples of things that COULD be Sidechains of bitcoin; but I still don't know what CANNOT be a sidechain.  

One fundamental property is that each sidechain is supposed to be designed, implemented, and managed by an independent team.  Therefore the bitcoin developers cannot give any assurances that the sidechain will do what it claims to do, or will follow any constraints.  

According to the paper, a sidechain can even have its own tokens, not pegged to the bitcoins that were exported to it.  I cannot see how the sidechains could help bitcoin scale to hundreds of millions of users -- except by being altcoins independent of bitcoin.

As I see it, the 'chain' part of 'sidechains' would be a bit of a misnomer.  I'd imagine all sidecoins to have a chain to use as an interface layer but not necessarily as a back-end.  I would hope that it is close to true to say that there is not much which 'cannot' be a sidecoin.  I've argued (sort of) to Adam that a token back-end makes more sense for a lot of use-cases than a '(now)classic' chain-based system.  Of course I'm limited in what I can 'teach' Dr. Back about...well...almost anything.

As for Blockstream's 'design, implementation, and management', I've seen nothing which indicates that it will differ from any other open-source project and nothing to be threatened by (unless you have a burning need to feel threatened of course.)  If that changes, so will my stance toward Blockstream.  And, I expect, so will many of those who are currently organized under that tent.

Blockstream either said straight-out or I inferred that that intend to produce an open-source reference implementation for sidechains.  In that case, anyone could pick up the ball and run with it.

Quote
As for LN, I have not followed it that closely.  My impression is that it is subtly different from how I envision sidechains, but very interesting technology which will be valuable to develop and experiment with if nothing else.

The LN is very different from sidechains.  It executed payments by means of "bitcoin IOUs" that are guaranteed by actual bitcoins that were locked by users for a predetermined time.  While sidechains are too unconstrained, the LN is too constrained.  

From all that I know, it has some formidable practical problems, like requiring that users lock in advance all the bitcoins that they intend to spend for the next 6 months into bank-like entities.

I have asked about these problems directly to Adam Back, Luke Jr, and a few other developers, including Joseph Poon, one of the LN inventors.  The dialogue always ends at that point.

The thing about LN that really impressed me was the 'slack'.  Once in a while I pull the keys out of my pocket and a quarter comes with them and falls in a gutter.  That does not stop me from using coins and having pocket change.  From an engineering perspective there is a huge amount to be gained by having a little room for error.  That the designers were cognizant of this impressed me...although it is rather obvious to anyone who has done systems work.

I'll not speak for the LN developers, but as a general design goal a fraud-proofing perspective, the most critical thing is to not allow an operator to profit from fraud.  This will almost completely evaporate many forms of fraud from even being attempted.  A distant second priority would be how long it takes me to get my value back in the event of a failure (which I would expect to be an uncommon event and one I may never see.)

Well, right now, if they control Blockstream, they control the future of Bitcoin...
Considering that most of the Bitcoin 'core developers' who are worth a shit are involved, that would be true with or without the Blockstream umbrella.

The fact that sidechains and Blockstream has you (Stolfi) running scared is one of the best indicators yet that the may live up to the hopes I have for them.

So you don't mind having the bitcoin network literally owned by one company, which intends to make it unusable for its original purpose and to reuse it as an internal component of their nonsensical project... It makes me very hopeful that bitcoin will collapse -- not under external attacks, as bitcoiners always feared, but from the greed and mistakes of its defenders.  It will be fun to watch...

Blatant and bogus propaganda on several levels:

 - Open source means that they not only welcome competition but foster it.  So down goes the 'one company' BS.  Blockstream only need to do it better, and that is highly likely given the makeup of the entity.

 - Nothing about sidechains in any way detracts from the ability for individuals to use native Bitcoin except perhaps that they won't be subsidized and will thus have to pay transaction fees proportional to the cost of operating a secure system.

 - Given the level of talent who were induced to work on this project, you should think a little bit about who looks like a clown when you label it as 'nonsensical'.

I do sense that you are deeply hopeful that Bitcoin will collapse.  Again, I suspect that this is why Blockstream and sidechains bothers you so much.


Blockchains are the new hotness in compsci and fintech.  That a compsci professor still views them with skepticism at this point (five years on) indicates Stolfi is either letting his political objections color his technical analysis, or he's just too proud to admit being wrong and upset he didn't buy in earlier.  Or he's an idiot of the 'those who can't do X, teach X' variety.

Stolfi's (now infamous) "I think XT will win" opinion indicates he is spectacularly unreliable as a source of valid predictions (despite his ostensible qualifications).

That's a shame, because the community can always use insightful critics to keep our groupthink in check.

Unfortunately, Stolfi has now demonstrated his positions originate from technical incompetence and/or bad faith.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
September 04, 2015, 06:54:36 PM
To be sure, Mike's patch had logic along the lines of:

1> Get list of Tor exit nodes from trusted third-party.
2> Running out of nodes.  Must be DDoS.  I bet Tor is behind it.  So, I'll just "lower the priority" of Tor, effectively refusing Tor connections until this DDoS stops.

Besides the obvious trust issue in #1, #2 has these issues:

- Effectively bans Tor connections even if Tor is not the source of the DDoS. 
- Even if Tor was the source, even Mike admitted it will prevent innocent Tor users from reaching the nodes.

Add to this the many reasons stated on bitcoin-dev why DDoS are far more likely to come from non-Tor sources, and this unduly punishes Tor users (and Bitcoin) with virtually no benefit to the nodes or Bitcoin. 

In fact, with this in place on a majority of Nodes, anyone could cripple Tor users by launching a DDoS attack on the Bitcoin nodes without even using Tor to launch the attack!

Either Mike is incredibly lacking in intelligence, or he wants to intentionally cripple Tor. Given his redlists proposal and his propensity for proposing introducing centralized trust to Bitcoin, the latter is very possible.   


[email protected] isn't trying to break Bitcoin, he's trying to integrate levers into it which give his MiB buddies discretionary control.

Fuck him and the former core dev he rode in on, as well as their astroturf mob of redditurds.

legendary
Activity: 1442
Merit: 1001
September 04, 2015, 05:56:33 PM
To be sure, Mike's patch had logic along the lines of:

1> Get list of Tor exit nodes from trusted third-party.
2> Running out of nodes.  Must be DDoS.  I bet Tor is behind it.  So, I'll just "lower the priority" of Tor, effectively refusing Tor connections until this DDoS stops.

Besides the obvious trust issue in #1, #2 has these issues:

- Effectively bans Tor connections even if Tor is not the source of the DDoS. 
- Even if Tor was the source, even Mike admitted it will prevent innocent Tor users from reaching the nodes.

Add to this the many reasons stated on bitcoin-dev why DDoS are far more likely to come from non-Tor sources, and this unduly punishes Tor users (and Bitcoin) with virtually no benefit to the nodes or Bitcoin. 

In fact, with this in place on a majority of Nodes, anyone could cripple Tor users by launching a DDoS attack on the Bitcoin nodes without even using Tor to launch the attack!

Either Mike is incredibly lacking in intelligence, or he wants to intentionally cripple Tor. Given his redlists proposal and his propensity for proposing introducing centralized trust to Bitcoin, the latter is very possible.   


Without any mitigation, an attack where nodes are full of inbound connections will effectively block all new connections, including Tor / proxy users. Full inbound connections is a problem - the question again is how do you prioritize which connections to drop?

Any attacker than can fill inbound connections on a lot of nodes is going to cause problems for everyone. Doing nothing is an option - it's what the reference client does. Or XT can prioritize. It's not exactly a stupid option, albeit not super effective.
sr. member
Activity: 504
Merit: 250
Earn with impressio.io
September 04, 2015, 05:11:54 PM
To be sure, Mike's patch had logic along the lines of:

1> Get list of Tor exit nodes from trusted third-party.
2> Running out of nodes.  Must be DDoS.  I bet Tor is behind it.  So, I'll just "lower the priority" of Tor, effectively refusing Tor connections until this DDoS stops.

Besides the obvious trust issue in #1, #2 has these issues:

- Effectively bans Tor connections even if Tor is not the source of the DDoS. 
- Even if Tor was the source, even Mike admitted it will prevent innocent Tor users from reaching the nodes.

Add to this the many reasons stated on bitcoin-dev why DDoS are far more likely to come from non-Tor sources, and this unduly punishes Tor users (and Bitcoin) with virtually no benefit to the nodes or Bitcoin. 

In fact, with this in place on a majority of Nodes, anyone could cripple Tor users by launching a DDoS attack on the Bitcoin nodes without even using Tor to launch the attack!

Either Mike is incredibly lacking in intelligence, or he wants to intentionally cripple Tor. Given his redlists proposal and his propensity for proposing introducing centralized trust to Bitcoin, the latter is very possible.   
sr. member
Activity: 299
Merit: 250
September 04, 2015, 12:54:08 PM
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?

On the basis of consistent maxing out of inbound connections. Are you suggesting that one can observe a DDOS attack from a specific group of IPs (TOR exit nodes), but without specifically associating them with a proxy network, this is impossible? This implies that these IP addresses are being blacklisted because they are part of the TOR network -- not because they are a likely source of DDOS attack.

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.

It's unlikely indeed. That's partly why this is so silly. It's like attacking a plague of locusts with a knife. If you were an attacker, you would attack on clearnet. Indeed the source of DDOS are usually botnets, not TOR nodes.

A node could begin to isolate IP addresses that repeatedly connect to it when inbound connections are maxed out and begin assigning lower and lower priority to them. The point should be to mitigate a DDOS attack, not throw an umbrella of suspicion over proxy networks. At the least, there should be evidence offered here that TOR exit nodes -- in comparison to any other set of IP addresses -- can be reasonably expected to be a source of DDOS attack. A simple anecdotal observation that a DDOS attack came from the TOR network is not sufficient evidence of that. One would need to take a much more comprehensive overview of all IP addresses that may comprise DDOS attacks over time.

This is probably more tied to Mike Hearn's mindset, which is to say, TOR/proxy traffic is for illegitimate use and non-TOR/proxy traffic is for legitimate use ("exchanges don't use it"). Perhaps a baby step on a long slippery slope.

That's also part of the reason that throwing a fuss about it is essentially just trolling - it can't be used to break bitcoin.

I don't think this was ever about "breaking" bitcoin. But it may be the wrong precedent to set and serve no real purpose.
legendary
Activity: 1442
Merit: 1001
September 04, 2015, 12:43:48 PM
Lulz, not sure why some people seem to think that the limited amount of exit nodes and limited bandwidth of Tor would be a good source for DDoSing.
Most successful DDoSes use botnets which are open IP addresses.

Targeting Tor IPs as a scapegoat for DDoS is like targeting Bitcoin to blame for all illegal activity.

Sure - I agree that it's an edge case where it would be activated and a smaller edge case where it would be helpful. That's also part of the reason that throwing a fuss about it is essentially just trolling - it can't be used to break bitcoin.
legendary
Activity: 4690
Merit: 1276
September 04, 2015, 09:33:22 AM
Lulz, not sure why some people seem to think that the limited amount of exit nodes and limited bandwidth of Tor would be a good source for DDoSing.
Most successful DDoSes use botnets which are open IP addresses.

Targeting Tor IPs as a scapegoat for DDoS is like targeting Bitcoin to blame for all illegal activity.

Who authorized you to apply logic and something approaching an mild understanding of today's network infrastructure?

I've always thought that what would make a dandy botnet would be a large fleet of SPV wallets, and in particular one's which were calling mothership regularly for 'checkpoint' updates.  The actual owners of the devices (who, parenthetically, are also the one's paying their service fees) would be largely to stupid to know that they were even being used like a bitch, and if they did they would be easily convinced that they are 'playing their part' in something worthwhile.

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
September 04, 2015, 08:12:02 AM
Lulz, not sure why some people seem to think that the limited amount of exit nodes and limited bandwidth of Tor would be a good source for DDoSing.
Most successful DDoSes use botnets which are open IP addresses.

Targeting Tor IPs as a scapegoat for DDoS is like targeting Bitcoin to blame for all illegal activity.
legendary
Activity: 1442
Merit: 1001
September 04, 2015, 07:53:41 AM
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.
hero member
Activity: 714
Merit: 500
September 04, 2015, 02:20:47 AM
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?
sr. member
Activity: 299
Merit: 250
September 03, 2015, 06:06:45 PM
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.
legendary
Activity: 1442
Merit: 1001
September 03, 2015, 06:02:32 PM
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. 

 Huh

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.

hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
September 03, 2015, 06:58:48 AM
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. 

 Huh

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
legendary
Activity: 1442
Merit: 1001
September 03, 2015, 06:40:47 AM
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. 

 Huh

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.
hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
September 02, 2015, 10:14:37 PM
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. 

 Huh

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...)
legendary
Activity: 924
Merit: 1132
September 02, 2015, 10:07:24 PM
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. 
sr. member
Activity: 504
Merit: 250
Earn with impressio.io
September 02, 2015, 08:46:07 PM
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. 
legendary
Activity: 966
Merit: 1000
September 02, 2015, 01:56:27 PM
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.
legendary
Activity: 1593
Merit: 1004
September 02, 2015, 01:46:53 PM
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.
Pages:
Jump to: