I thought the win by Masten for the 2nd tier prize of the Northrup-Grumman Lunar Lander Challenge was completely legitimate. The "shenanigans" was simply following the rules, and that they won the "tie breaker" over Armadillo Aerospace. Yes, John Carmack wasn't too happy about the way they lost, but let's get real about the issues involved.

BTW, while Armadillo Aerospace (not Masten) was one of the original X-Prize teams, the Lunar Landing Challenge was not technically one of the "X-Prizes".. even though Peter Diamandis and the X-Prize Foundation were requested to act as the judges to determine who was the legitimate "winner" of the contest rules might be, it was more legitimately a part of NASA's Centennial Prizes (or Centennial Challenges) series of competitions and the seed money came from the U.S. Federal Government as a NASA appropriation. I know it is splitting hairs, but it is disingenuous for the X-Prize Foundation to be claiming this as one of their own projects even though apparently they have.

The impressive thing is that Armadillo Aerrospace wasn't the only company involved in the "competition". BTW, I was also impressed with Unreasonable Rocket, who has continued to do other things since the competition as well. Perhaps the best thing that happened is that Masten got some important seed money by winning 1st place for the level 2 competition, and they've spent that money in a very wise manner while Armadillo Aerospace has been well funded because of John Carmack. Both companies (AA and MSS) have also worked with NASA on various projects in an attempt to leverage the expertise learned from the Lunar Landing Challenge, noting that the challenges they have in terms of control systems working here on the Earth are actually going to be tougher due to the high gravity than what they are going to need on the Moon or asteroids.

The point of the challenge (especially Level 2) is that the delta v needed to win the prize was the same as what would be needed to launch from the surface of the Moon, go to a lunar rendezvous orbit (like what the Apollo project did for their Lunar Orbit Rendezvous scheme), and then safely land back on the surface of the Moon (or the other way around). In theory, both companies now have the technological capability of being able to land and retrieve rock samples from the surface of the Moon with their vehicles... if only you could get those landers to Lunar orbit in the first place.

Are any of the Grumman engineers still around to build a follow-up module if we ever want to go back? Most of them are either pushing up daisies or collecting retirement benefits... think about it.

I'm glad that *somebody* is working on these skills in some way to make sure that the capability is even possible.

I'm also glad that computing power has advanced beyond discrete transistors and 7400 logic gate chips that are the size of your thumb, because that is what the original Apollo Guidance Computer was built out of.

If anything, an ICBM needs to travel as fast as it can, and have a huge acceleration for the purpose of reducing reaction time for incoming warheads. That goes completely against the design philosophy of launches intended for spaceflight, much less a rocket-powered lander. A typical nuclear warhead is really quite sturdy and can handle high acceleration forces (100-200 m/s^2 are common, sometimes up to as high as 400 depending on the missile). A typical satellite payload package usually is only built to handle forces up to about 50 m/s^2 (about 5 "G's") and some launchers try to drop that acceleration even further.

The point being that I agree with you (and not the grandparent) in terms of any danger in terms of weaponizing these kind of rockets. There may be some common components for commercial spaceflight launchers and what you can find for military missiles, but there are enough major differences that they are not interchangeable. This is especially true for "modern" rocket designs, where there is a clear separation of the designs because they have different objectives in terms of flight profile and performance characteristics.

If commercial spaceflight pushes the boundaries even more, this differences is something I think is going to be even more pronounced as rockets are being designed not for high performance but rather to simply be cheap. This rocket made by Masten is definitely pushing the envelope of being cheap. The budget for this project is something equivalent to a "petty cash fund" that is so low it doesn't need any specific appropriation legislation to make happen. I don't know the exact amount Masten is getting from NASA, but it is in the mere thousands of dollars, certainly less than a million. Normally NASA can't even do a paper study for less than a million dollars, much less pay for a working rocket.

You can trace mined coins to specific IP addresses if you are careful with how you listen to the packets and try to find out which computer gave you the packet first. If you had several computers tracking this information, it would be possible to identify down to a small number of users who actually mined some Bitcoins, and from that if any Bitcoins were co-mingled with those mined coins to be able to further identify what other addresses might be used by that person who also is mining coins.

Still, attempting to do that is a real technical challenge and you would need the resources of something like the U.S. federal government to pull that off, plus a whole bunch of data mining and active participation in the Bitcoin network... and it still gives wiggle room for plausible deniability on the surface. If there was a particular set of transactions that such data mining was looking for, you can still be tracked.

On the other hand, if you were very paranoid about such things you could set up manual connections for routing Bitcoin data to only trusted nodes (by your own definition... not some random list in other words), and hopefully even they are being just as paranoid about random connections "to the outside world".

You can use coins until RFID tags get put into them. Seriously, even cash transactions can be traced.

BTW, in terms of serial number trackers for U.S. currency, this website does a pretty good job:

http://www.wheresgeorge.com/

This isn't even paranoia, and you might be surprised at how much of the cash in your wallet is being tracked.

On the other hand, every single transaction for the entire history of Bitcoin from the day the original root block was created is clearly available for anybody in the world to look at. You can identify not just the amounts but to whom it was paid, "processing fees" associated with those transactions, and a detailed "chain of custody" for every Bitcoin.

There are ways to anonymously transfer Bitcoins, but in and of itself Bitcoin is not nearly so anonymous as some people make the claim it is. The tough part is linking a particular Bitcoin address with an IP address.... which is a much harder proposition to make. Even that isn't impossible, but it can be much harder. It is much, much easier to perform that step if you happen to operate one of the major Bitcoin exchanges, as you can link the BTC information with user registration information and connection data to the exchange website.

The other saving grace is that most Bitcoin transactions are of such petty values that it would never trigger a reporting event in the first place even if it was a normal monetary transaction.

The algorithm has an adjustment factor based upon how long it took to generate the previous number of blocks (I'd have to dig into the algorithm to find the exact number). If one day a huge amount of CPU power is suddenly dumped into Bitcoin in an attempt to hoard the coins, the adjustment factor increases by a factor that compensates for the increase in computing power.

Sure, over a short period of time you will generate a whole bunch of new blocks as the system adapts to take in the new amount of computing power, but eventually the algorithm adapts to the sudden influx of new blocks solved and makes it harder to create the next block. So with your example of 300 new computers jumping into the system, those computers will at first have the ability to create blocks with the old difficulty level... until they start churning out new blocks and grabbing the available coins.

The opposite happens too, where a whole bunch of computers leave the network (people give up trying to find bitcoins) and then it simply takes longer between blocks. When that happens, the algorithms reduces difficulty after a few blocks are "discovered" and then it eventually becomes easier to find the next block.

There is a lag in how quickly the algorithm takes to adjust, and note that random events will also make some blocks naturally appear sooner simply because of random chance.

The best way to describe the search algorithm is more like playing something like the multi-state lotto, where your computer attempts to find the "winning" numbers, and when you find the correct numbers you have "won" the lotto for that 10 minute time period (for a whopping 50 Bitcoins). The difficulty adjustment factor is more like having to pick seven numbers instead of six, or perhaps it goes up to eight or nine numbers, and when it becomes too hard because nobody is winning the string of numbers you need to pick goes down. This isn't a perfect analogy, but if you are familiar with lotteries it might make a little more sense.

It isn't that hard to implement "fixed decimal point" mathematical algorithms. It can be done on any computer which has integer opcodes... which is just about every computer ever built since ENIAC. The rounding you are referring to is due to floating point numbers where the numbers are rounded when they are put into the data format in the first place.

Making a "fixed point data type" in C++, C#, Java, or other more modern languages is simply creating that data type in the first place, and most of those languages have operator overloading for those data types that make the task trivial once you've implemented the type. I'm sure simply looking around can find find that already written as a library, but any programmer worthy of the title should be able to create these data types from scratch in those languages.

C and its derivatives also move strings around very efficiently, but I'll admit the programmer interface into accessing those functions is clunky and obfuscated, while COBOL does it as a designed behavior of the language.

As for static variables, the problems that come from the dynamic variables has more to do with how programmers using those languages have been taught to use them, where dynamic variables are considered ordinary and the developers insist upon pointer references in libraries and common interfaces. Again, it doesn't have to be done that way, but the API standards push it to be that way. COBOL comes from an earlier time when such techniques simply weren't taught.

Traditionally in Mainframes they had larger bus sizes and register sizes, which for fixed point calculations is critical. With most microcomputers having 64 bit registers as a common practice and even some low-end game consoles having 128 or even 256 bit registers, the real strengths of mainframes in terms of computing power is almost lost. About the only benefit to mainframes any more is strictly the uptime and circuit redundancy for hot-swapping components. For computing tasks that take hours or days to complete, that can be very important.

A hinged door, at least an ordinary hinged door, doesn't have nearly so many moving parts and therefore is much less likely to break down. For new vehicles, I realize that isn't nearly so big of a deal, but in time sliding doors can be a real pain to work with, particular with older vehicles. They just need a whole lot more attention.

One problem that you've glossed over here on the sliding door, however, is that the door can only be as long as the side of the vehicle, or you have to invent a really exotic system to physically carry the sliding door. Generally there is a track on the bottom of the vehicle that the door slides upon, and that must be at least as long as the door itself. That track BTW is also one of the sources of problems, if it gets gummed up with "stuff". That is something you don't find with any other door system.

One nice thing about the gull-wing doors (or more like the Model X) is that there isn't any real limit on the length of the door. They can be as large or as small as they need to be with the design of the vehicle being used. There is a support mechanism that must be put into place to hold the door up while it is open (so it doesn't go slamming onto your hand or fingers), and that is also where you are most likely to see some sort of mechanical failure as well.

An ordinary hinged door doesn't have those problems.

In terms of the plug, I don't see the difference between the power consumption of a heavy electric appliance like a kitchen range, electric clothes dryer, and an electric automobile. Yes, the power consumption is a bit higher, but not significantly so. I think you could build a "fool proof" plug and have some resemblance of safety... although your point is very valid that the amount of energy going through that cable is huge and needs to be treated with respect. You certainly don't want to have some firefighter using the "jaws of life" and cutting through that cable in some kind of vehicle rescue attempt. It certainly isn't like trying to install a car radio... which is very low voltage and comparatively low amperage.

In terms of the salt water spray and other things getting onto the battery and cable, I'd agree that is a big deal too. Imagining somebody pulling into a Chicago battery swap station covered in snow, mud, and salt in the Winter and then somebody reaching through a puddle of that muck to unplug the battery pack..... I shudder at the thought.

Then again, people have been known to die from dispensing gasoline. Usually doing very stupid things (like some woman with nylon stockings getting in and out of her car building up a static charge and then grounding her automobile to the gas pump right at the nozzle) or simply being careless.