I think you need to review the purpose or meaning of having a currency "backed" by something. The whole point is that the real value is in the scarcity of the currency or resource backing the currency. Anything that is truly scarce can "back" a currency because it represents an expenditure of resources that can't be counterfeited. This is why gold has value. Mining gold takes resources (time, transportation, and exposition of which are the most difficult to come by -- merely finding the gold) which you never recover, but the gold itself is the valuable asset that backs itself and/or other currencies. Bitcoin, then, could be viewed similarly. You spend the resources to acquire a new bitcoin by "mining" it, which you should never expect to get back, just like you can never expect to get back the time and other resources you spend to mine gold. Bitcoin, like gold, retains its value in its quality of scarcity. You can't get another one without expending resources relative to its value. That's why the existing bitcoins retain their value and new bitcoins add value to the bitcoin economy. They don't need any external backing because they are scarce and represent a past expenditure of resources, just like gold.

That does seem odd. I wonder if the 40km^2 is only required for large scale optimal receivers whereas if your power requirements were less or more of an emergency, less efficient receivers could be justified at a size that would be more portable and temporary.

I think this is about motivation. And (admittedly not having read any details) in general, I agree more with what I assume to be Sarah's perspective than what I assume to be Linus'. I would rather be motivated intellectually than emotionally. Emotions have unequaled power to motivate people to action (as the marriage debate has demonstrated), but I don't think it's the right way to *be* motivated -- out of fear or greed. Actions should be taken because they make sense, not because you're afraid. The primary emotion that should motivate me is satisfaction in my intellectual integrity and accomplishments.

Is my sleep deprivation impacting my ability to comprehend what is being said here, or are others having trouble understanding what is being said in this article/abstract too? I understand the headline, but I can't quite understand how the words in the article support that simple statement. People who own older copyrighted material can exchange it more freely and easily and can communicate with copyright owners and... what? I'm really missing some point here. It looks like gobbledygook generated by a random thesis generator to me.

I think there's a little bit of disconnect between the people asking this question and the people answering this question. I think the people asking the question are wondering "Why encrypt the piece of information that lets you get at the rest of the information if the rest of the information is right there plain as day?" and the people answering the question are explaining, "passwords use one way encryption so they can't easily be hacked." Yes, one important reason for encrypting the password is to allow some time for users to change their passwords before the passwords are cracked. But I think to answer the question more directly, passwords often give access to a lot more information than just what might have been compromised. Yes the cracker got a hold of a lot of un-encrypted information in this case, but if the passwords were also in plain text, they might have been able to get more information than they did. Some people use the same password for multiple sites, and some sites may store information in multiple locations so that the password could have provided access to more information than what was lost. If passwords were stored in plain text, someone would need only to be able to see the password in order to access all of a user's information, and sometimes that's easier than getting all the information that the password protects.

Well, this should be entertaining seeing how this plays out. I see the following possibilities:

1. They prove they're a ridiculous and wrong target, case closed;
2. They begrudgingly negotiate some kind of corrective action that they have the power to take, and some believe will have some effect, but probably instead leads back to conclusion #1;
3. They are dissolved, and the problem doesn't go away, leading back to conclusion #1.

This is starting to look like DMCA all over again. Person creates software and claims they can't be held responsible for how it's used. Argument and legislation goes into effect pointing out that the software cannot be used for anything legal, and is this illegal to use/develop (can't remember that important detail). Software becomes illegal and original person is left only with the option of creating legal alternatives.

Could it be argued (with even any small degree of merit) that they have the ability to make new client software available that would institute new features that include the ability to track transactions in a way that would comply with laws? And since they released the original client (did they?) they might be held responsible for releasing an updated alternative client. Do you foresee this happening, and then nobody adopting the software and then legislation going into effect to try to ban the use of the old software?

The "Magic: The Gathering Online Exchange" is not the only thing backing Bitcoin. It's just the first/main exchange where you can convert between bitcoin and USD. There are other exchanges, and there's nothing stopping you from directly buying or selling BTC for USD on an individual basis with other bitcoin enthusiasts. BTC value is determined by the demand among the general population, not by the exchanges themselves.

BlueMonk's corollary:
Those resorting to Geekoids law as evidence that something is likely wrong have done so as a result of being unable to find anything specifically wrong, or as a result of a desire to participate in a discussion without expending any effort.

What you say is true in some cases, but I think is an over-generalization in this case. In this case, I think it is a matter of designers not maintaining an awareness of the full domain that gender encompasses. It's something that may be difficult to go back and correct, but not something that's difficult to deal with if you maintain an awareness of it from the start, which is exactly why this kind of issue needs to be brought to our attention.

As an example, imagine the issue of assigning serial numbers to items you produce. Assume some companies like to assign serial numbers when they ship items, but others like to assign serial numbers to items the moment they come out of the manufacturing process. Having to support both these methods is significantly more difficult (requires more resources) to design and implement than choosing one and allowing its assumptions to ripple through the system (I know because I've done this). You can make assumptions about whether you need to track serial numbers for everything that happens with an item in inventory if you know which route you have taken.

In this example case you have elements of each decision that exclude functionality of the other. If you choose to have serial numbers assigned only at delivery, you may have to introduce extra logic to compare how many items in inventory have serial numbers versus how many exist total and ensure the number of serial numbers don't exceed the overall quantity, but still allow zero or more of the items in inventory to have serial numbers (if you accept returns of defective products after they are delivered). Whereas if you assign serial numbers for all transactions as soon as the item enters inventory, you can assume that the number of serial numbers should always equal the inventory quantity (simpler math and validation process), but then you have to support entry of serial numbers on many more transactions. And if you want to support both methods, you have to deal with both sets of complexity, plus the added complexity of identifying which system is active plus the possible complexity of allowing switching between the systems. So this is a good example of how identifying an average or common case would significantly simplify software design and implementation.

But on the question of gender, I don't think the similar complexities apply in most cases. Most systems treat gender as a simple reference field of little integral consequence to the rest of the data. All the software designer has to plan for, in most cases, is what the valid values are and whether it can be changed. Sure, if you want to support the writing of a salutation ("Mr." vs. "Ms.") in automated letter writing software based on gender, you may have an issue, but:
1) I suspect that letter writing software is not a majority of gender-aware software out there;
2) If the salutation is important to you, you should be storing the salutation separately anyway instead of basing it on gender;
3) The complexities introduced even in this case are trivial if you have an awareness of and plan for them (it's not hard to include an extra field for salutation or to use a first name instead if you don't have a salutation field);
4) Supporting a third gender option like "U" in which the salutation uses the full name instead of a generated salutation is not mutually exclusive with any of the standard gender functionality. (A system that supports "U" doesn't cause the handling of data without "U" values to become more complex.)

Similarly, the question of whether to allow updates to gender after it is assigned seems to be more of a design oversight than a true issue of software complexity. There are usually many other fields in the same area that *can* be updated, and if you know ahead of time that Gender is one of these, it's not hard to allow.

That covers the technical aspect, but the issue also has procedural impacts - requiring documentation for proof of gender, for example. Why do we require documentation to allow a gender change? It's all part of validating a person's identity (if I read the article correctly). But handling the "average case" here (where an average person doesn't need documentation to prove their gender) doesn't change the fact that there are non-average cases where gender does change. All it does is make it harder to deal with the cases where it does change (and harder to be certain that a person's gender is what is recorded for them). The fact that the system doesn't support a means to change your gender doesn't prevent one from doing so. Take the example in the article of a driver's license. Physical attributes of a person are presumably printed on the license to help ensure that a person is using their own license. What good does it do, then, to make it difficult to change your gender? It helps to ensure that you can't walk into the DMV with someone else's license and make it reflect your own identity. So how is the average case streamlined here? The average case is that gender doesn't change. You completely eliminated and ignored the issue. The issue is that there *are* transgender people - how do you deal with them? Well, you can require a lot of paperwork and make the "average" transgender case very difficult to deal with (the problem that started this discussion), or you can base all transgender issues on one document (like a birth certificate) that you only need documentation to change once. That's what they did here, and it actually became *more* streamlined requiring *fewer* resources, while still maintaining the integrity of the identification systems.

So saying that this is a case where the average case has to be assumed for performance reasons, I think, is an excuse not to think about the problem in depth. I think there are a vast majority of cases where the problem is a lack of awareness and not a lack of resources to address the design issues.

They do have a point, though, that the average bitcoin user is probably less susceptible than the average overall user to phishing attacks because most phishing attacks are relatively easy to detect and avoid if you have any tech smarts, which most bitcoin users need to have in order to be involved or have an interest in bitcoin. Questionably how pronounced that variation from average is, though.

Yeah, but that's not news. All Windows users (and some others) have long been targets of virus and other malware attacks against which the many available defenses are not always 100% effective. Nothing new there. You don't have to be a bitcoin user to be the kind of target you're describing.

My point is that there is a simple fix that's not a perfect fix, but is probably good enough to satisfy most of the people having problems. To improve the results further without making it any more complicated. It might make sense to display 2 clocks:
GMT: ##:##:##; Local*: ##:##:##
* Local time is based on your computer's clock

I don't disagree that it's not a simple problem (that is to say, I agree that it's not simple), but it's also not so black and white because there are intermediate fixes that are simple, better than previous behavior, but maybe not ideal or perfect. Most computer clocks are correct within 15 minutes and already take into account summer/winter time and time zone (and some even adjust time zone automatically as they travel), so why not take advantage of some of that in the easiest way to get a good 95+% fix. By simply rounding the difference between the local computer's time and BBC time to the nearest 30 minute mark, then applying that difference to BBC time, you'd get a pretty good result, I think.

For example:
My time = 08:45
BBC time = 14:43
Difference = 5:58
Rounded difference = 6:00
Adjusted (displayed) time = 8:43

As for moving through time zones without adjusting your clock, I expect my computer to show me the time for the time zone I have it set for or the time zone of the size I'm visiting, not some arbitrary time zone based on something I don't understand.