So what sort of practical applications does a HomeDaemon-MCP installation have -- and why would you, if you're a small business (perhaps in the homebuilder, HVAC, security or renovation space) want to buy the package and monetize it?

For the math on a plausible basis look here.

I want to focus right now, however, on the practical side of it -- the user experience side.

These are all things I'm doing right now in one way or another in my home.  If you've got a serious interest in acquiring the package I'll be more than happy to meet with you and show you -- from afar -- exactly what I'm talking about and how easy it really is.

• You're at the bar, a half-hour from the house.  You'd like to use the hottub when you get home.  So you open the page (on your phone) and hit "Hottub On." You can see the current temperature of the water and a few minutes later you get a text message that the heater has been confirmed to be working; when you get home you pop right in.  Behind the scenes the system has reset the valves on your combined pool/hottub system, put your VFD-driven pool pump (which you have saved several hundred dollars a year in power by installing) on "high" for the hottub, and monitored the heater's temperature rise to make sure it ignited.
  
  
• You get out of the hottub, having enjoyed several adult beverages, and forget to push the button to shut it off.  30 minutes later, sensing no movement in your Lanai, the system does it for you saving your a scadload of energy you would have otherwise wasted heating the water all through the overnight hours with nobody in it.
  
  
• You have your laundry machines in the utility room.  You stick a load of laundry in the washer.  When the washer finishes the cycle the system notifies you that the load is complete via both announcement on the house's speakers (over which it can also play music) and via text message, just in case you happen to be out working in the yard or relaxing by your pool.  Contrast this with the washing machine down in the basement or in the utility room and it's "weak sauce" end-of-cycle buzzer you cannot hear.  Ever leave a wet load in the washer by accident overnight this way?  Yeah, that's disgusting..... 
  
  
• You leave the house, getting in your car.  An hour later the house automatically adjusts down the A/C, saving your money, it texts you so that you know it went into the "secure" mode and in addition it starts monitoring the occupancy sensors to indicate not that someone is in a room but that someone may have broken in!  If it detects same it takes a picture through your webcams and sends it to your phone via email, and texts you immediately.  Instead of having a contract with a security company and getting fined by your local PD for false alarms if the sensors trigger you get to check it out and, if there really is a problem you can call the sheriff's department directly.  No more false alarm charges and a higher-level of security, plus good photographic evidence to use in prosecuting any actual burglar, is the result.  Oh, did I mention no "monthly fee" games from the security company either?
  
  
• You get home later, and the system detects you coming in through the garage door; it shuts off the security and returns the A/C to its former setting.  The occupancy sensors go back to turning your lights on and off for you automatically, without any user intervention.  Just to make sure it really was you the system also sends you a brief text message so you know the house has turned off it's "secure" mode.
  
  
• You aren't around for a weekend.  The system, being in "away" mode automatically, runs a reasonable simulation of an occupied dwelling, with a pattern of lighting suggesting someone is there -- during the evening hours only, of course.  When someone unexpectedly comes into the driveway the floodlights all around the home come on, perhaps providing a deterrent value should that be a burglar.
  
  
• You have a room with two lighting switches but when one is on you really would like the other to be on or off at the same time -- and at the same brightness.  You declare these as "grouped" in the system; pressing the paddle on one (whether on, off or to change the dim level) causes the other(s) to automatically follow.  You can also "group" a switch (e.g. when you have a light on you want the ceiling fan to be on, and if you shut off the light then the fan should be shut off as well) with a dimmer circuit.
  
  
• You go to bed, and push a button on your nightstand.  All the lights in the house go out and the HVAC system is adjusted to your preference for a more-comfortable sleep.  The outside perimeter motion sensors, should they be triggered during that overnight, will turn on the respective floodlights and, if motion is detected in your lanai, not only will all the lights be turned up fully there but a chime and announcement will sound inside.  Home invaders who think they'll catch you sleeping beware!
  
  
• You wake up a couple of hours earlier than normal and decide you're going to get up, which is unusual for you.  You like to sleep in a cool house, so when you went to bed you had the system turn down the heat -- and it's February.  You reach over to the nightstand and press button "3" briefly (of 4 on the wireless remote you have velcro'd to the side of your nightstand.)  The thermostat on the other side of the house is immediately set to it's normal daytime level plus two degrees and your two-stage furnace comes on, quickly warming up the house.  In a few minutes, instead of getting out of bed in a 65 degree house and walking out to the thermostat to turn it up, you have a nice toasty room in which to work your way to the bathroom and your morning shower.  An hour later the thermostat resets back to the normal daytime temperature setting all on its own; no point in wasting energy keeping the house extra-warm for the rest of the day.
  
  
• You have installed a "push button" deadbolt so your kid can come home from school without having to carry a key.  When you go to bed and everyone is home the keypad on the deadbolt is automatically disabled, so even if your kid is foolish enough to tell someone what the code is it's worthless to use in invading your home in the middle of the night.  In the morning the keypad is automatically re-enabled.
  
  
• Your cleaning lady uses the code to get into the house.  You're reasonably ok with this because you can connect to your security cameras and see what's going on at any point in time, plus motion triggers them to take pictures.  The cleaning lady only comes on Wednesdays between 10:00 and Noon; the system sets that code at 9:45 AM on Wednesday and revokes it at 2:00 PM.  The rest of the time your kid can use his code to get into the house after school, but the cleaning lady's code is worthless.  Being in secure mode when she shows up you get a text, and another when she keys the code to lock the door on the way out.  If she doesn't use the code the second time to lock the door (she forgets when she's leaving) an hour after she leaves you get a text telling you the house has "re-armed" itself automatically and the door is locked -- on its own.
  
  
• Your kid, like most, refuses to shut the lights off when he leaves a room.  The system automatically turns them on and off for him.
  
  
• You want to watch a movie and would like the living room lights on, but at a very low level.  You push a button on your phone and they all change to "nightlight" level illumination, along with modifying the light level in the nearby hallway and kitchen on motion detected in the area so your movie doesn't get interrupted with bright lighting when your kid decides to come into the adjacent kitchen and get a soda from the fridge.

• You want a very low level for the lights in your bathroom at 2:00 AM if you need to get up to pee, but in the evening you'd like a moderately higher level of lighting - and your wife wants to be able to crank it up when doing her makeup.  All automatic; if you get up to pee at 2:00 AM you get a "nightlight" level of illumination sufficient to make sure you don't try to sit down on an up toilet seat, but during the day and evening hours the level of illumination is altered appropriately.

None of this requires "programming" as you think of it.  The list of what to do and when to do them is controlled by a simple English-like language, similar to this:

[z Front Door Motion] triggered on
[v Night]
execute
cmd zset 50 Front Door Lights

Which says "if the front door motion detector just changed state to on and it's nighttime then set the front door lights to 50% brightness."

The system can handle, and will process, a nearly-unlimited number of conditions like this.

The best part of it is that other than for licensing restrictions (if whoever winds up owning this wishes to sell a time-limited right to use, much like Adobe does with their "Creative Suite") there is no connection required to any sort of "cloud resource" of any kind.  The system runs entirely independently, on the local device and yet maintains a security model that allows you, and only you and those you authorize, to access it via any web browser-capable device from anywhere.  Your phone, your tablet, the computer at your office, your laptop -- literally anywhere, all securely and under your exclusive control.  You can also define a number of access levels for that information so some people (e.g. your kid) can control things in his room but he can't screw with the light levels in your room.

Oh, and it all runs on a $35 computer without even getting it to breathe hard and boots off an SD-card, making it entirely power-fail safe.  Power consumption is roughly 5 (yes, five) watts.  Yank the cord and when you plug it back in it comes right back up as if nothing had happened.

Look to the right if the opportunity sounds juicy to you!

Here's some more on the license server that was recently added to HomeDaemon-MCP.

One of the biggest issues that faces any software publisher today is piracy and security.  The two are intertwined; not only do you lose sales (maybe a lot of them) to piracy, but what's worse is that stolen copies of the code frequently have "special features" (viruses and similar nasties) added to them, and since most software installers run with privileges this is a huge problem since the user grants permission for the code to install.

If that happens to include a trojan, cryptolocker or other nasty the user is screwed.

HomeDaemon-MCP of courses faces the same challenge, were I to start distributing it or if someone buys it and starts distributing it.  The code also inherently uses cryptography via the OpenSSL library, which it must to (among other things) provide a SSL-protected web server so you can control and monitor your home without other people breaking in.

For those who haven't run a web server with a certificate before in order to have the little padlock show up on user's displays you must have both a certificate and key.  The certificate is public and anyone can retrieve it but the key must remain private.  In addition someone has to "vouch" for that certificate and key belonging to you as being actually yours, which is why there are companies that sell said certificate certification services (e.g. Comodo, Verisign, etc.)  The idea behind "public" certification authorities is that they allegedly actually vet who someone is (at some level, which depends on the service bought and paid for) and supposed are trustworthy (that is, they won't allow anyone to impersonate them and, for example, issue a bogus certificate.)  There's plenty of reason to believe the latter is definitely not true if the person doing the insisting on impersonation is a government agency, by the way (since a government can insist rather loudly including by locking people up or even shooting them if they refuse), but for ordinary brigands and thieves it's probably secure against such games.

In the realm of a private device there's no reason to pay for a public certificate though; you're not a business taking money from the random public. In that case the company that sells you the "thing" is, if trustworthy (and if not why did you give them money?) probably good enough.  However, the requirement for a certificate that is vouched for by someone you trust still exists or anyone can stick a random certificate that claims to identify your site "in the middle" and by doing so decode all the traffic and steal it -- including your password, at which point breaking in becomes pretty darn easy!

HomeDaemon-MCP has always allowed you to specify who is the "root" of that trust in the certificates it uses.  This is now part of what the license server provides.

In addition the certificate and key are also provided by the license server.  That is, formerly if someone stole (or "borrowed") your SD card they could trivially read the key file since it's physically there and virtually any computer can read an SD card -- suddenly your system is not secure any more.  That's because if the key file has a password on it (which would prevent its use, at least without a lot of resource to crack it, as it's encrypted) the software can't start on its own after a power failure because there's nobody present to put in the password.  This by the way is true for most web servers as well, which is why most of them in "ordinary" commerce rely on the physical security of the device rather than a password on the private key for the certificate in question.  This is mitigated by the fact that if your certificate is compromised (e.g. you learn someone may have stolen the key file) you can ask whoever issued it to revoke it and reissue a new certificate, which of course you'd do after generating a new key (and fixing however the old one got stolen.)  As a result the utility of stealing a key on a webserver is somewhat limited since the certificate it is linked to is easily marked compromised (in other words explicitly "do not trust this") and replaced.

What's been coded into HomeDaemon-MCP to effect the "boot up" is a pair of certificates -- that is, CA certificates to validate the connection to the license server.  There is both a root certificate (for which the key is stored on an offline piece of media in a safe and an "intermediate" certificate (which has its key available to sign regular certificates.)  This particular intermediate certificate signs only one server certificate -- for the license server.  Rather than read them from a file the system instead has them coded in the executable.  If these keys are stolen from the server side, that is, if whoever is running the license server itself has a security problem then you'd have to reissue all the keys anyway since you must assume they've all -- including the server's certificate and issuer certificate -- have been compromised.  As a result there's little downside to this approach; if such a breach occurs then the binaries would have to be recompiled and re-issued and until they are, the old ones would refuse to talk to the fixed license server with its new certificate chain.

In addition the server and client sides are both coded to insist on extremely high security connections; if a client tries to connect using something that can be replayed or is not sufficiently safe the server will refuse.

Now when the HomeDaemon-MCP code starts up it asynchronously starts to not only run as usual but also tries to acquire a license set.  It does so by sending a unique hardware ID, a user-specified password and cryptographic hashes of both the executable being run and the operating system kernel.

The server then validates all of this against its data, specifically:

• Is the hardware ID known to the license server?  That is, did the user steal the software and is trying to use it on multiple (or an unauthorized) piece(s) of hardware?
  
  
• Is the password correct?  That is, is the user's assertion of being the owner of the hardware in question reasonably "good"?
  
  
• Is the executable's hash good?  That is, not only has it not been tampered with (essential) but is it an authorized revision (useful)?  This allows the license granter to, for example, only allow "free" updates for a certain period of time.
  
  
• Is the kernel's hash good?  This is one the license granter may not care about, but on the other hand they may.  It provides the ability to gate support and operation to a list of known-good operating system kernels.  Since a tampered-with operating system is even more dangerous than a tampered executable this is arguably quite a good thing.  However, it is somewhat limited in that the overhead cost of real-time cryptographically checking every operating system component is extremely high, and thus that's not attempted.
  
  
• Is the place the connection is coming from ok?  The current code doesn't check IP addresses against a white or black list, but there's no reason it can't since every connection has an endpoint and TCP connections will not work unless they are valid in both directions.  This doesn't stop someone from "bouncing" off another address but it can prevent someone from using a license in an area that the granter considers "prohibited" (e.g. Iran, China, etc.) without the user taking extraordinary steps.

If the server doesn't like any of the parameters passed to it then it simply shuts down the connection and goes away with no response at all.  The client code will keep trying a couple of times a minute.

If and only if it likes all of the parameters provided then it responds with an operational CA chain for the web and master server, the certificate and key for same, and, if the client is authorized to run as a slave node, the certificate and key for that (which is distinct from that used for the web server.)  All of this is sent over a PFS-encrypted channel and thus is useless if the raw data is captured and replayed even if you somehow manage to later steal the license server's private key.

The HomeDaemon-MCP code installs those credentials and as a result encrypted mode operation, including web access, immediately becomes functional.  A couple of times a day, or if the code is restarted (e.g. after a power failure) the same scenario repeats so if updates are made to the license data the new certificate(s) and key(s) will be loaded.

Since access to the web server functionality is pointless if there's no web access at all (e.g. no access to the Internet) the short delay during startup means nothing since you, as the user, can't get to the service until internet access is restored.  Because license acquisition takes place asynchronously event processing starts immediately and operates normally even if the server is unavailable for some period of time -- but you can't get into the system to manually control or monitor it as the web server (and master capability) is effectively non-functional, immediately closing any connection attempted as the system knows the security credentials are missing.

At no time is any of the returned data stored locally, and there's also no buffer space in which to stash it in the code; instead it is dynamically allocated as required and then immediately cleared when no longer needed.  Therefore if you were to force an attachment and RAM dump of the executable you might be able to recover the credentials, but the the amount of code-hacking you'd have to do to make that information usable in the binary would be quite severe.  The other alternative would be to hack the binary to disable secure-mode operation entirely.  However, if you managed to pull off not only killing the checks but also enabling the access without the credentials you would basically destroy any pretense of security in the application itself and thus render it not only worthless to the user but potentially quite dangerous since random people on the Internet could quite-trivially break in and/or steal your login and password!  In addition if the legitimate licensee figures out you did any of this with his certificate and key he can sign into the license sever's client side and request that the server revoke it.

As such this appears to be pretty good as a security model.  Nothing is perfect; all commercial applications suffer from some risk of hackery and this is no exception, but as applications go since access to the outside world is basically required and secure access to same is also required in order to make it safe hacking out the protection scheme, if violated through hacking on the binary, leaves you with a highly-compromised piece of code that nobody in their right mind would use to control anything.

The License Server code as it sits right now runs against a flat directory structure and doesn't check kernel and executable hashes, or against a Postgres database -- with the query process entirely configurable.  The latter is also multi-threaded making possible very high levels of performance.    What won't be included is the customer-facing front end that handles people setting up their accounts and paying, since that's highly specific to whatever sort of payment model and collection system (e.g. credit cards, PayPal, etc) you wish to use.  I can of course code something along those lines up for a price -- or you can, if there's not already an appropriate "cart-style" web application that fits your needs or that you already have.

As a reminder HomeDaemon-MCP is for sale "lock, stock and barrel" and in source form; my previous article on the potential market is here, and the page on some of the capabilities can be found here.  Finally, there's a not-yet filed provisional patent related to the code that, for obvious reasons, I won't be going into any sort of detail on but will file same before turning over anything that could lead you to figure it out.  Who knows what that's worth, and the acquiring party will be free to file the permanent application and pursue its perfection and issue, should they so choose.  It's entirely possible that patent is more than worth the asking price on its own, incidentally..... but of course as with all things of this sort nobody knows until it's filed and marketed.

Look to the right for contact information.

I've been harping on this more-or-less continually since 2011 -- it relates to your personal health and reliance on the health care system in the United States.

Specifically, if you look like you're pregnant and you're not (or can't be) -- let's just make it simple folks; if you stand in the shower, look straight down, and you see gut instead of genitals.....

You can ignore this (again), if you want.  But time's pretty-much up.

Trump's "tax cuts" are going to accelerate the deficit spending trend that Obama (and Bush before him) initiated.  The Fed's machinations over the last 100+ years are utterly irrelevant because all of them are in fact driven by Congress.  The Fed is a creature that operates at the behest of Congress, as a creation of Congress, and every single dollar it has "printed" it has "printed" because Congress spent money it did not have.

In other words, Congress ran a deficit.

The Fed has its share of detractors and I'm among them.  But those who refuse to place responsibility where it belongs are fraud-running jackasses, and while I'm happy to try to educate folks those who refuse to learn and cling to that which is trivially disproved mathematically wind up on my "ignore" list.

The bottom line: It is Congress, which is elected by you, that has destroyed the purchasing power of the currency and enabled all of the fraud and force in our economy today.

Every.
Single.
Bit.

Health care costs have exploded because of fraud, extortion and just plain intentional bloat.  Hiring ratios of 10-30:1 for administrators to doctors and nurses are just a start.  You pay for every one of those people but they never provide a single second of care to a single person.  This crap standing alone is strangling the economy and it's strangling the Federal Government.

Then you add onto it monopolist protections system-wide.  You can't get a price before a procedure and you can't hold someone to a price.  How much you pay has nothing to do with the complexity and everything to do with how you pay (or whether you can.)  The health system is the only form of "business" in which a hospital or physician bills you for fixing their screw-ups -- and if those screw-ups kill or permanently maim you they're "entitled" to bill you for that too.

The entire health system in this country, top to bottom, is a racketeering enterprise on grand scale, it currently consumes one fifth of all money spent in the United States, stealing at least 80% of that, and in many cases produces negative or zero net value while doing so.

The Federal Government knows this.  It also knows that if the Attorney General, Congress or the President puts a stop to it there's a monstrous recession -- in fact, from an economic definition perspective an immediate Depression will result.  It wouldn't last long and we'd be far better off when it was over but the next 12 to 18 months would be nasty and whoever is in office at the time will get blamed -- and lose their jobs.

As a result none of the people in office -- not federal, state or local -- will do it unless the public rises and demands it, making clear that there are three -- and only three -- alternatives: Do it, leave peacefully and be replaced by someone who will, or rest in pieces.

Ultimately the people of any nation have the right to issue such a demand -- but only in concert, as a body politic.  1776 was such a demand and when the answer "nuts!" came back from the British monarchy the colonists reply was "ok, since you insist in pieces it shall be."

No lone person has the right to do it (we call that terrorism) but the people as a body politic always do, provided the alternatives are laid on the table.  That's the very premise on which a representative republic is based.

Well, you won't do it.  Not collectively, or in sufficient numbers.

You'd rather get screwed on-balance.

As a result your only alternative is to not need the medical scam.

Sadly if you do need it and the tipping point comes -- which may be as early as this year, you're going to be severely hosed -- or worse, dead.

There's much more, of course -- autos, "higher" education and other areas of grift and scam (FANG-cough-cough!) but this one you can actually take some level of personal control over and thus to a meaningful degree evade.

I've written many pages on this topic, and unfortunately there are some who have enough bad luck, or have just let things go too long, for whom there is no way out at this point.  There's nothing that can be done if you're in that position.  But if you're not, and most people who are today dependent on the medical scam can make a difference, then you're running out of time -- fast.

Start reading, and start doing.

Sorry, but no.

Dec 13 11:30:25 HD-MCP HD-MCP[46870]: SSL Handshake failed at protocol level on [120.210.191.60]
Dec 13 11:30:25 HD-MCP HD-MCP[46870]: SSL ACCEPT Error [http request] on [120.210.191.60]
Dec 13 11:30:57 HD-MCP last message repeated 40 times

Nice try asshole.

No, you can't break into my HomeDaemon-MCP server.

No, you can't break into my home control system.

No, it doesn't have a cloud connection, no, it won't talk to you without signing in, and no, you can't get in without first negotiating HTTPS either.

And no, attempting to hammer it won't piss it off.

Psst.... the codebase continues to improve and the opportunity is still there, if someone wants it.

Bet against my view on "Make America Great Again".

And have about a million and a half to put on the table in support of your belief.

For what?

HomeDaemon-MCP.

So let's say you spent the $1.5m and acquire everything.

Here's a hypothetical way of looking at the opportunity.

There are roughly 80 million single-family, detached homes in the US. (I'll ignore condos, mobile homes and townhouses, although some of the first and last are potential customers as well.)

We'll also assume you can appeal to just 0.1% of those single-family homes.  That's a tiny penetration.

But it would amount to 80,000 installations.

The hardware cost to install is under $100 for a minimal install (that's the power that comes from running on a $35 hardware base!) and under $500 for a typical install including sensors and control points (e.g. switches, etc.)

We'll assume you sell the base hardware and software alone for a one-time price of $350, and 50% of your installs go that way (homeowner does the rest on his or her own.)  That's $10m in gross profit.

The real money is in the annuity stream and installed systems.  We'll assume those have a minimum install of $1,500 billed out, of which $500 is your fixed cost.  That fixed cost includes $100 for the controller and $400 for a mix of motion sensors and controlled points.  Install time is 3 hours @ $60 each for skilled labor, or $180.  That's $820 across 40,000 installs, or $32.8 million.  We're now to $42.8 million in gross profit.

Now assume you use the certificate system built into the software and slightly extend it (yes, I can do that on a contract basis, or you can if you have a competent programmer on staff, since the framework is already in the code) to add an annuity-style revenue stream for maintenance, updates and offer an option to the customer for same.  We'll assume you charge $20/month for this and half your 40,000 install-it-for-me customers go for it.

That's another $4.8 million a year in revenue and the effort to issue the certs is about 1 minute each per year.  You can automate that, of course, but there will be expense in doing so.  Of course the actual time spent servicing said customer is variable (and you'd have to take a guess on that), but over 3 years that gets you to $57.2 million.

We haven't yet included what you can make off the "higher end" installations (the million dollar+ homes and condos) where the owner wants not 10 control points but 30, and is willing to pay for it.  He gets convenience, security (e.g. access to his IP cameras and triggering points from them), no cloud required so Google, Amazon and others do not have access to the inside of his home, ever, and you get to sell that -- it's private, it's his or hers, and it's accessible and controllable from anywhere in the world via said secure infrastructure that has no access for anyone other than him -- including you!

Let's assume that of the 40,000 "you install" locations 10% of them are truly high-end homes (remember, we started with 0.1% penetration into the market and now we're at 10% of 50% of those) are not $1,500 installations, they're $3,000+ installations and your gross margin on those is 50% -- which is easily achievable.  That's another $6 million in gross profit; we are now at $63.2 million.

Is this a reasonable projection over three years time?  It's in the game.  No, it's not "riskless" by any means, but on an adjusted risk:reward basis it looks pretty damn good.  In fact, it's not all that far off what I accomplished with MCSNet in terms of return-on-invested capital.  The real return is always on sweat equity as that gives you much more control for the risk you take, but you have to have something that affords you enough operating margin to make it worth it.

Of course there's SG&A to be accounted for.  How good of a businessperson are you?  Cost control is a big part of the game in any business but any line of work is a hell of a lot easier to succeed at when you start with a nice fat margin on the goods and services you sell up front.

This is a 40%+ gross margin business, in short, as I analyze it, and in areas where you have existing people I bet you can sell to vastly more than 0.1% of the households.  Certainly in many metro areas far more than 0.1% are in the $300,000+ price category where a system like this is a tiny percentage of the home's price yet the value delivered in convenience, energy saving and security dramatically outweigh the tiny uptick in cost generated by including or adding it.

So if you're "MAGA" or just believe my view on monopolists, the rule of law and such is horribly pessimistic and wrong, and in addition have the cash to put on the table to back your position with a big fat check then come do so.  Show me that my pessimism is unwarranted the best way anyone ever can -- by making a bunch of money that I am intentionally leaving on the table, handing to me just one fortieth of what I could have had.  We'll drink a beer together when you prove my view on the business environment in the US to be unreasonably pessimistic and you'll laugh as you motor away from the pier on your new yacht.

Of course the above is all "back-of-the-envelope" speculation but that's how a decent functional business plan starts being developed.  It's how MCSNet was developed originally, but before it was actually executed on I fleshed it out and actually wrote a full five-year business plan with pro-forma financials.

The difference between doing something like this and the Ponzi scheme nonsense peddled by many on Wall Street such as belief in 30% growth figures into the indefinite future when you already have half the nation on your service (cough-amazon-netflix-facesucker-cough-cough!) this sort of back-of-the-envelope pencil-out assumes 0.1% penetration into potential buyers.

What happens if you can get 2% penetration?  You make well north of a billion, and then you really laugh at me.

So if you're both "accredited" (you almost-certainly are if you have the capital) and this makes you salivate look right, click and email me.  We'll talk.

When I started MCSNet my view on business changed. I don't consider a 10% gross margin to be attractive at all.  IMHO if you can't get into the 30s it's not worth it on a risk-adjusted basis, and the target is 40%.  IMHO this, while certainly not "buy it and sit" like speculating in something like Bitfraud, fits that category -- but since success is of course directly related to both your analysis (rather than mine) and how you execute (rather than how I execute) this is all hypothetical, but if that 0.1% penetration can be turned into 0.5%, well...... you do the math.