Monday, October 21, 2013

Bathtub analogy

A good way to understand inflation is through the bathtub analogy. Think of a bathtub as the economy. The size of the bathtub is the size of the economy. The water is money. The current water level is the price level. This analogy is fairly precise, as long as you imagine that the bathtub can grow or shrink. If the bathtub gets bigger, i.e. the economy enlarges, the water level (prices) obviously will decrease. If you add more water (money), the water level will increase. If you add more water at the same rate as the bathtub gets bigger, the water level won’t change. And it doesn’t matter where you add the water; the overall water level will rise. However, it won’t necessarily rise all at once. If you turn on the shower and distribute the new water more-or-less evenly, the water level will rise all at once. But if you turn on the tap and put all the new water into one end of the tub, that end of the tub will rise first, and the other end of the tub will rise last. In that time, where one end of the tub has more water than the other, those at that end have an advantage: They have the new money, and can buy goods at the old prices. Near the end of the process, when everywhere but the far end of the tub has evened out, those at the far end are facing the new prices, but don’t have the new money yet, so they are at a disadvantage.

It’s important to note that inflation will occur regardless of where or how money (water) is added. Regardless of whether the Fed prints money and hands it to the banks, or whether Congress prints money and spends it, or whether everyone owns their own printing press and prints money for themselves, the water level will rise based on how much water is added to the tub, not how it got there.

Under our current system, the Fed is the faucet, and the wealthy, in particular the banks, are at the front of the tub. They receive the new money first, before the economy is able to adjust, and can buy things at artificially low prices. The poor and those living on fixed incomes or solely on interest (such as retirees) are at the back of the tub. They get the new money last, so they are facing artificially high prices.

Thursday, September 26, 2013

OpenPGP key transition statement

Hash: SHA512

Hash: RIPEMD160

Date: October 16, 2013

For a number of reasons[0], I’ve recently set up a new OpenPGP key, and will be transitioning away from my old one.

The old key will continue to be valid for some time, but I prefer all future correspondence to come to the new one. I would also like this new key to be re-integrated into the web of trust. This message is signed by both keys to certify the transition.

The old key was:

pub 1024D/BB9EC476E934D755 1998-09-22
Key fingerprint = CD29 354E 5C51 E528 0E0E 19DF BB9E C476 E934 D755

And the new key is:

pub 4096R/BEB8C013FCC700F3 2013-10-16
Key fingerprint = 0AA7 230B 8C3C 2C2E 12E9 525D BEB8 C013 FCC7 00F3

To fetch the full key from a public key server, you can simply do:

gpg --keyserver --recv-key BEB8C013FCC700F3

or if you’re using GPGTools for Mac[1], choose “Retrieve from Keyserver…” from the Key menu in GPG Keychain Access and paste BEB8C013FCC700F3 into the “Key ID” field.

If you already know my old key, you can now verify that the new key is signed by the old one:

gpg --check-sigs BEB8C013FCC700F3

or with GPGTools, choose “Show Info” from the Key menu in GPG Keychain Access when the key is selected, choose the “User IDs” tab, and review the Signatures field.

If you don't already know my old key, or you just want to be double extra paranoid, you can check the fingerprint against the one above:

gpg --fingerprint BEB8C013FCC700F3

or view the fingerprint in the Key tab of the Key Inspector in GPG Keychain Access.

If you are satisfied that you've got the right key, and the UIDs match what you expect, I'd appreciate it if you would sign my key. You can do that by issuing the following command:

NOTE: if you have previously signed my key but did a local-only signature (lsign), you will not want to issue the following, instead you will want to use --lsign-key, and not send the signatures to the keyserver

gpg --sign-key BEB8C013FCC700F3

or choose “Sign…” from the Key menu in GPG Keychain Access while my new key is selected.

I'd like to receive your signatures on my key. Once you’ve signed it, please upload the signed key to a public key server:

gpg --keyserver --send-key <my email address> [sorry, I don’t post my email online to avoid spam]

or choose “send public key to Keyserver” in the Key menu of GPG Keychain Access when my key is selected after you’ve signed it.

Additionally, I highly recommend that you implement a mechanism to keep your key material up-to-date so that you obtain the latest revocations and other updates in a timely manner. You can do regular key updates by using parcimonie[2] to refresh your keyring. Parcimonie is a daemon that slowly refreshes your keyring from a keyserver over Tor. It uses a randomized sleep, and fresh tor circuits for each key. The purpose is to make it hard for an attacker to correlate the key updates with your keyring.

I also highly recommend checking out the excellent Riseup GPG best practices doc, from which I stole most of the text for this transition message ;-)

Please let me know if you have any questions, or problems, and sorry for any inconvenience.

Jim Syler

Comment: GPGTools -

Comment: GPGTools -