So how many independent legal advisors say that the other independent legal advisors are wrong? There are always at least 2 sides to the issue and you don't need to be a legal advisor to decide what works best.

When they actually start winning some courts cases (last I checked years ago, they lost), then I'll put more thought into the issue.

You are depending on something that no one know exist yet though. That's it's possible to create an army of CPU for less than it will cost to steal those millions. I'm sure botnet operators would fall into that category, but if anyone owns that much CPU power, they would make more money stealing from the existing electronic currency market (think global stock market) than trying to take control of bicoin. Plus you forget that we are still here watching everything, as this is an open source community. If you can get the entire community to remain silent for a global bitcoin conspiracy, then bigger problems are at hand than someone cheating bitcoin.

Security through obscurity certainly isn't possible with bitcoin and that's it's strong point.

Apples to oranges I'm afraid.

That's like asking that we take the SETI data and apply it to Gene folding.

BitCoin works off a Secure Hash Algorithm, so we can't throw gene data or radio frequency data into it and build a working chain of proof.

You skip a lot of steps.

It would be me saying "When people are tired of government, I should be able to take over the world".

That's a social problem, not a technical problem. 

Then I suggest, going to them and asking for license. Just like SCO will give you license for Unix still for some money.

You want to send someone a payment for 10BTC and it puts up a warning "it's going to cost 1010 to send the BTC?" 

Nope, no, and not yet. I've tried that myself, the clients just ignore it all.
Nope
Nope
A lot of us have already attempted everything you've listed here. That's why we have a lot of security updates for releases 

About the only thing that will make any of that work is having more CPU power than the entire swarm and the currently difficulty. Reverse time chains, slow DoS, fast DoS, swarm manipulation, wormholes, and time travel have all been tried so far. But if you come up with some unique, we'll be glad to try it.

I've always liked the Mantis bug tracker, though it's not a GUI friendly/pretty, mainly just a down and dirty text driven model with colors. 

http://www.mantisbt.org/

Older CPU that don't support SSE2 shouldn't be excluded from coin generation in my opinion. They can still serve a vital role in block generation; I have many machines that don't support the SSE2 enhancements, but still generate blocks all the time, even if they are only churning 300-400 khash/s

Speed isn't really much of an issue since the p2p is for transactions and block data; not large files. Latency is probably a good goal; have a well connected swarm insures transactions are processed quickly and block data is updated quickly so clients don't lag behind the rest of the network.

Mainly, he doesn't want home routers to get overloaded by the p2p part of bitcoin.

At the same time, those that have bandwidth and CPU to spare can set a high limit (like 1000 or more) that just acts at a super-node for the rest of the nodes to connect through.

I do the see point because a non-SSE2 machine, the client would crash?
Depends on which is easier really. If you enable something that is going to break compatibility, the only people who will feel the pain are the non-technical users of the client. From their perspective, it just doesn't work for some reason.

I think some builds notes would be better, example (If compiling on a 64bit system, be sure to do this part).

Have one branch of source that cross-compiles across multiple operating systems is always tricky business. 

Not on 64bit linux, just 32bit and 64bit everything else in between (Linux/Windows)

I didn't notice until I checked the generation dates against the release dates of the software.

If you don't strip the debug symbols the binary is 8 times it's normal size.

As far as I can tell, the supernode is just another node like any other, but has more connections to other nodes (instead of trying to keep around 8 or so). The only thing that offers is redundancy and faster coin spending. It won't speed up confirmations.

In the first case, redundancy; just means all the nodes it's connected to will have at least one node that remains connected all the time. As people open and close their bitcoin client, your client is constantly losing and making new connections to other nodes. Being connected to a super node means it's just one less connection for your client to find if it has less than 8.

Second case; it also works as a shortcut across the swarm if your client and the client that you are sending coin to, happen to share. So if you are 12 node points away from the person you are sending coin to, there will be a little delay before the transaction broadcast goes through. If both are connected to the super node, then it's less metric distance for the transaction to travel. So it might or might not allow faster transaction time, there are many factors to consider for that part (ping, real world distance, etc.)

I think an unconfirmed third point is it helps the network maintain honesty among the nodes in regard to keeping every other node highly connected. Super-nodes are just really clients willing to connect as many nodes that will accept, network together. So it's willing to do a lot of work for the other nodes in a more active role than a passive role.

They certainly aren't necessary for BitCoin to work, but they do provide a benefit and every little bit helps.

Remember that Certicom's patent claim pertaining to ECDSA is still just a claim. I haven't seen anything that established them ownership of it since they filed back in 1999 and everything freaked out, but if anyone has an links to some hard court cases, that would be great.

Otherwise, I wouldn't worry about it because since then, a lot of the world governments and big business already use this. I don't know how well they would stand in a lawsuit against the entire planet?

This works for the 64bit builds, strange that it has no affect on the 32bit builds? Should it be disabled for 32bit builds as well?

After testing the 32bit and 64bit builds, the problem I can confirm what was already posted here, it just affects the 64bit builds. When I go back and trace what's being produced, it's the 64bit Linux machines (the 64bit windows machines don't appear to have this problem) that aren't producing any coin since the latest releases. All of the 32bit builds (stock or custom) appear to be just fine.

I'm starting to wonder if the two are connected now since the hashing seems to get stuck, maybe that's why it gets stuck on a block.

Should be simple enough for CentOS, I was going to test it out first to see if those suffered the same issue, thought it seems like all the builds would suffer this issue if the compile flag is what makes the difference.

I just tested it out, I get the same results. Repeating values with stock, more random values with the flag modification. Probably needs to be fixed for the next release, though I'm not sure how mine are generating anything then?