Bacon-days and the value of financial freedom

I'm big on saving; I'm even a disciple of Mr Money Mustache. But an exercise in happiness ROI I did recently got me wondering about whether our consumerism is the most rational choice.

To measure the ROI of any investment in happiness, we need a system for measuring happiness. I propose the use of 'bacon-days'. One bacon-day is the enjoyment you get from eating one piece of bacon every day. I like this measure because I can always remember or re-experience exactly how much happiness a piece of bacon gives me. We can use bacon-days to estimate the happiness we get from something compared it's cost.

First, let's estimate the happiness ROI of acquiring financial freedom. I'd say not having to work is about the same happiness as having a piece of bacon every 5 minutes. So, 8hrs/day * 60mins/hr / 5mins/bacon = 96 bacon-days. That's the return. What's the investment? Over the last 50 years the S&P500 increased an average of 7.2% per year after inflation. If you had $2M at 7.2% you'll be making $12k/month before taxes. That's a good salary with some buffer. Now we can calculate the ROI. That yields a total of 96/$2,000,000 = 4.6E-5 bacon-days/dollar.

Now let's compare that to something else I want. For example, a bean bag chair. My wife and I will only be able to cuddle in it for once a week to watch a movie. During that time I'll enjoy it equivalent to about 4 pieces of bacon when compared to the current setup of two separate chairs. 1/7 week/day * 4 bacon/week = 0.57 bacon-days. That yields a total 0.57/$130 = 4.4E-3 bacon-days/dollar. Wow! I want that chair two orders of magnitude more than I want financial freedom!

But the chair is an easy example; everyone owns and believes in the value of chairs. What about something that really seems frivolous? For example, I want a plasma cutter. I do a little metal-work and I already own a band saw that does pretty much the same thing. But a plasma cutter would do it faster and I could do some more complex cuts. A plasma cutter and the compressor it needs to run will probably cost me ~$2000. Historically speaking I do a substantial metal-working project every 3 months or so (making a ladder/water-tower, making shelves, making railings, throwing a welding party, etc.) In any given project I'm probably making ~20 cuts. The joy I will get from making a cut with a plasma cutter instead of waiting on that noisy band saw is at least the same enjoyment I get from eating a piece of bacon. That works out to 1/90 projects/day * 20 cuts/project * 1 bacon/cut = 0.22 bacon-days. That yields a total of 0.22/$2,000 = 1.1E-4 bacon-days/dollar. That's still more than double the ROI of financial freedom.

Does this means I should pursue buying such seemingly frivolous things instead of saving for early retirement? It seems like it. I know these simple equations don't consider the value-decay of objects over time, but when something is an order of magnitude more ROI, unless it'll break that year or the next we can often discount value-decay. I'll have to think about it more.

House now has solar power

The solar monitor told me my one panel was making 1.2kWH/day. It's time to actually use that.

The cheap solar setup I made uses a $30 charger and a $40 inverter. I already had 4 old lead-acid batteries in a scooter I didn't use and I'd previously bought the most expensive part; the panel.

All told, it took about another $100 worth of switches, cabling, conduit, etc. But now we generate 1.2kWH/day, can store 400WH, and can use up to 400W at a time. Not a lot, but my chest freezer uses ~800WH/day so once the system is proven I'll probably have it run that.

Solar Monitor V1

The goal: Understand how much power a solar panel actually makes.

The most straightforward way to measure DC power is to give your source a resistive load and measure voltage across it. Power = Voltage^2 / Resistance.

Challenges we face: The problem with solar panels is that they can't be approximated as constant-voltage or constant-current. So just one resistor isn't enough. Further, I don't want to have to run power or networking outside. So whatever device does this measuring it needs to itself run off of the solar power and either save that information or convey it wirelessly.

Solution: First, let's use an 'Arduino Yun'. This is an arduino printed on the same PC board as a linux machine with the serial connection and software already made between them. So the linux machine can do the networking side of it while the arduino can do the more typical microcontroller functions; turning the resistors on and off and measuring their voltage.

For power, we can use voltage regulators 7812 and 7805 to bring the 38V of the solar panel down to 12V where a battery will store it and then down to 5V where the arduino will consume it. With a large battery, it should have no problem lasting the night even in the low-light winter.

We also want monitoring, manual control, and safeguards.

Monitoring: For monitoring, I'll put an LED on the power coming in from the solar panel, and then one on each of the resistor networks to see if they get pulled low.

Manual control: For manual control, let's add three light switches (because they're cheap) to turn on overall power from the solar panel, power from the battery to the microcontroller, and then turning on or off the monitoring LEDs. Having LED control lets me turn them off when they'd otherwise be sapping power. Having two levels of power control let me boot the microcontroller only if I want to debug, or boot it first to get around uncertainty in startup, or not boot if the battery is dead, etc.

Safeguards: The resistors could take as much as 260W at peak but I don't want to buy and don't need a 300W resistor because I'll only be pulsing that power on for a moment to take a reading. Then it will have plenty of time to cool down. Unless something breaks... if power does stay on while the resistor is turned on, it could heat up, burn, and short out other parts. So I'll put in fuses in a few key parts to make sure if it does go melty it doesn't stay melty. I could also have a secondary system montor heat, but the complexity of the machine increases dramatically if I do that.

Results

It had two problems: First, it doesn't have enough grainularity of load. At full sunlight with 2ohms it did 16V and about 124W. But then at 8ohms it did 28V and about 100W. It should have been doing at least 200W and perhaps it would have been had it been at the ideal voltage of 24V. Perhaps solar cells have a much tighter wattage curve than I knew.

Second, it melted itself. Something bad happened and the 2ohm resistor must have stayed on. It was on until it melted the acrylic holding it in place, charred part of it's outer surface and eventually internally ruptured it's connection thus ending the short.

So the data was not good enough and the device was damaged. Need a new plan. :)

The Inconvenient Message Detection (IMD) prototype is done

Github URL, how to use it is in the ReadMe: https://github.com/DickingAround/InconvenientMessageDetection

The problem:

Who talks to who and who uses encryption is obvious to a mass-observer (e.g. the NSA). Large encryption keys and encrypted data are hard to hide. This leaves the meta-data of communication open for observation. It also leaves people using encryption vulnerable to coercion; an individual in power could demand they decrypt their communications.

The goals:

• Obscure who talks to who without requiring broad adoption of a new technology.
• Increase the cost of mass-observation.

Two communicating parties have to transmit something. The smallest message that can be transmitted is a single bit; 'there is a secret'. If it is reasonable to transmit this datum through insinuation, pre-determination, or other meat-space methods, then the meta-data of the communication is hidden.

The solution we've made:

Steganography that requires computing effort. Steganography is the idea of hiding data in the unimportant bits of an image. This is an old idea. The new twist is that with 'Inconvenient Message Detection' (IMD) that data can only be found if the decoder does an amount of computational work that's decided by the encoder.

Let's look at how this solved our problem: If some people use IMD, it makes every image suspect. When a mass-observer wants to see what communication is going on, they must use compute power to check every image. Furthermore, because the compute effort needed to find an image is set by the encoder, it is uncertain to the mass-observer; they never knows for certain if they've worked hard enough. By contrast, the intended recipient of a message presumably got the single datum that a message exists in some public image and will put in as much compute effort as is needed to find the data in that single image. Having every image on the internet be a potential carrier of secrets makes the mass observation of communication meta-data expensive and uncertain.

Furthermore, even a individual under direct observation can increase their protection with IMD. An individual may own thousands of images of which only one contains an secret. Until the secret is found by an observer, the individual has plausible denyability of the secret's existence. The observer may even give up before spending the necessary compute effort to find it. This increases their resistance to coercion.

The current program is only a prototype. I am a competent engineer, but not professional in security, encryption, or steganography. I am more than open to advice and help. (And here's thanks to all those who have already helped craft and refine this idea and implementation so far.)

How does it work, at a high level:

Obfuscation:

1. The image is hashed to create a number. That number is used to encrypt the file to be obfuscated. This encryption is only done to assure the bits of the file are evenly distributes between 0 and 1, it provides no other protection.
2. The image is hashed to create another number. That number is hashed a certain number of times as specified by the user. The result is used to seed a pseudo-random number generator.
3. The pseudo-random number generator is then used to decide where to put the 1s and 0s of the file into the image.
4. For each bit, there is a check to see if the pixel being changed will give away that the file exists (e.g. a '1' in a field of '0' saturated color). This check also makes sure we haven't changed the results of previous checks or written to this pixel twice.

De-obfuscation:

1. Same as encryption step 1.
2. Similar to step 2 except that after each hash, the image is checked to see if there is a file in it. This is continued until it finds a file or a the user stops it.
3. Same as encryption step 2.

FAQ:

Q: Can anyone read a message hidden with IMD?

A: Yes. IMD only obscures the existence of the message. Feel free to also use encryption to make sure only the intended recipient can read the message if it is discovered.

Q: How are you making it difficult to detect changes in the image?

A: I have a basic algorithm to avoid changes that would be blatant giveaways. This algorithm also serves to show where/how a better algorithm would be implemented (it's tricky to check a pixel and than conditionally change it). The basic algorithm checks for pixels which already are or are near saturated so as to avoid them. Also, pixels that are near others with the same value are not used. I assume there are better algorithms here, but I have not had time to research it.

Q: What about image meta-data? Often images have meta-data about the camera that took them. Is this disturbed? Does it give away the existence of a message?

A: No idea. This is the #1 feature on the list for a V2 of this program.

Q: What about lossy image formats like JPEG? Isn't that the most common image on the internet?

A: Yes, but it's harder to work with. In talking to a steganography expert, I gather it should be possible to store this data in the way JPEGs or other lossy formats are encoded since they are not deterministic. But it's harder so I haven't done it yet. That work would be very valuable. If you would be willing to to that work, please don't hesitate to contact me.

Q: Why are you using python's 'random' library? It's well known that this should not be used for encryption.

A: Most encryption wants/needs a random number generator, not a pseudo-random number generator. For example, os.urandom is a source of as random as possible. We don't want real random. We want a pseudo-random number generator; a random number generator that can be seeded.

In practice the 'random' library in python is an MT19937 with a period of 2^19937 which is to say it is highly impractical/impossible to parallel-test every one of those 2^19937 possible starting positions. Thus, the library works fine for how IMD uses it.

That said, feel free to swap it out for another for your own use.

Q: Why use AES to encrypt the message before encoding it?

A: I picked a symmetric encryption algorithm at random. It's only real job is to even the distribution of bits in the secret file such that there's no pattern of more '1's or '0's in the image.

Feel free to swap it out for another for your own use.

Github URL, how to use it is in the ReadMe: https://github.com/DickingAround/InconvenientMessageDetection

Ladder to the roof is done

The roof providers 1000 more sq feet of space on our house. It was designed to hold people, plants, a hottub, etc. But there's no way to get to it.

So I built a ladder. It's welded out of 304 stainless steel using 316 stainless wire in the welds. So there's no need to paint or prevent rusting. Though it is 17' tall (tall ceilings) we estimate it only weighs about 70lbs. We actually hoisted it by hand to the second level, using people roped in to the railings and lifting. My friends are good sports. :)