Sunday, December 9, 2018

What hash does Go modules (vgo, go mod) use for verification?

As mentioned in a previous blog, git's hashing mechanism isn't great.  At the time of this writing, the replacement is still not fully ready, let alone used. In my humble opinion, securely verifying code should be a primary function of git.  Git historically has been indifferent on this point.  It's argued git shouldn't be as it isn't security focused, while frustratingly containing a built in function to do just that. This means secure infrastructure must be a layer separate and above git. Languages or other ecosystems that use git must build their own systems.  

Go had no standard means of addressing this issue until Go modules.  Thankfully, Go wisely knew not to delegate this vital security feature to git.  This also allows seamless employment of other versioning system like mercurial or bazaar.  

A project's `go.sum` file can reference an external project like this: v0.0.0-20171218180944-5ea4d0ddac55 h1:jbGlDKdzAZ92NzK65hUP98ri0/r50vVVvmZsFP/nIqo=
In this example, the project didn't have a manually created version number set as a git tag, so Go created one.  `5ea4d0ddac55` is the first part of the git commit SHA-1 hash sufficient in length to reasonably avoid collisions.  A hash is nice to have as a component of the version number, but Go does not use this for anything security related.  Why then use a hash for a version number?  Time isn't sufficient as version should be related to what the code is.  By including parts of the commit hash, small changes will result in a different version number.  

But the line doesn't stop with the version.  The line continues and references "h1".  What an improvement!  Go modules is already anticipating using different hashing methods in the future.  What is h1?  Go modules uses SHA-256 as a hashing algorithm for the verification of code and econdes the hash in Base64.  More specifically, Go modules compresses the whole directory as a `.zip` and then hashes the results.  The local cache directory for the results are kept in `$GOPATH/pkg/mod`.  The file in the cache ending in `.ziphash` contains the same hash as in the `go.sum` file in a given project.  

Here's a couple relevant links to how this is accomplished:

Thanks to Go's new module system, gophers no longer have to worry about what git is using. Go's verification mechanism is totally separate from external versioning tools and Go modules uses git only for versioning.

Thanks Go!

Monday, November 19, 2018

How to repair a Electrolux canister vacuum with a dead head

I was generously given a Electrolux Ultra Flex canister vacuum bringing the total owned by my extended family to three.  Electrolux has since released a new model after mine was purchased.  

It sucks well, it cleans very well, it's decently quiet, fantastic on pet hair, it's great on stairs, and the vacuum itself is easy to clean.  

Overall, it's probably the best vacuum I've ever used, except one has had a few issues.  The clip for holding the wand upright broke, the retractable cord doesn't stop recoiling forcing me to use a clip on the cord when vacuuming, and worst of all the the head stopped working after a few months.  No lights, no roller.  The first two issues aren't a deal breaker, but a dead roller is a show stopper. 

I troubleshooted to an electrical issue where the detachable hose meets the canister.  The electrical collar had a bad connection.  I attempted to clean it of any debris but that didn't seem to help. 

I called Electrolux and they sent out another hose assemble with no problems.  After a few weeks the new hose died as well.  Since two hoses had died and Electrolux just released a new model I figured there was a design problem with the older model I owned.  At this point I decided to fix it myself. 

A few warnings:
  1. This is an electrical modification and you should know what you are doing.  
  2. The canister collar will no longer be able to spin.  This is a hard wire fix.  If this isn't suitable for your vacuuming style, you will need to find another solution.  This isn't really a concern for me.  
  3. Make sure this is the issue.  It was easy for me because I could interchange parts with other vacuums.  Also by wiggling the hose or holding it down it was obvious there was an issue with the base of the hose.  
  • Wire cutter
  • Wire stripper
  • Phillips screw driver
  • Three 1/2 stainless steal screws
  • Small gauge electrical wire insulator, like shrink tube or electrical tape/paint
  • Drill with a small drill bit.  
Open the collar port.  There's a single black screw to do this.  Then gently slip the outer collar from the inner.  An o-ring might slip out.  Be sure not to damage it or loose it. 

Slipping off the outer collar reveals two copper rings.  Removing the copper rings reveal the wires connected to the hose.  Cut the wire off the copper ring (and be sure not to cut the wire off from the hose!). The wires under the copper ring are bare and you will need to be insulated.  Put the o-ring back and slip on the outer collar feeding out the two wires attached to the hose.  

Now you're ready to hard wire.  The collar port contains two wires that attach to the main canister body.  Wire the black to black and white to white.  Use an insulator to make sure there's no bare wire that could short circuit.  

Now that it's hard wired, the collar _must not_ spin.  I drilled three small holes from the outside and used 1/2 inch stainless steal screws.  This will stop the base of the hose from spinning so that the new hard wired solution won't be ripped out. 

Finally, slip the collar port back on and attach the black screw.  That's it!  If you've had this problem like I've had with two of mine, that should fix the issue. 

Happy vacuuming! 

Friday, September 21, 2018

Gravity Wells are Sombreros

You've probably seen an illustration of a gravity well, something like this:

Or maybe you've seen one with Earth like this image:

Whenever I saw these gravity well depictions in school I mistakenly assumed they depicted gravity.  They don't.  These gravity wells depict gravitational potential, not gravity.  Gravitational potential tells you how much time is warped and how slow local time will progress due to general relativity.  It is now, however, correlated to what local gravity is.  These "gravity wells" would probably be better named "gravitational potential wells".  

Another problem is that these illustrations work fine for distances far away from massive bodies, but close this is an inaccurate picture of how gravity works. Xkcd's well known depiction relates planet radius to gravity, but this doesn't show how gravity works in the region of a massive body.

What do gravity wells look like near massive bodies? To illustrate, let's envision an empty area of space with a one light year radius and a single celestial body, something like Earth, in the center.

In this miniverse where is the least gravity and where is the most?

Based on the gravity well depiction, one might assume edge of this miniverse would have the least gravity and the center the most.

Now let's consider Earth. Where is the most gravity in Earth? Could it be the Dead Sea, the North Pole, the Mariana Trench, or Mt. Everest?

No, the most gravity experienced is almost 3,000 km below Earth's surface about halfway to the core. The least gravity would be the center of the planet. Consider this graph of Earth's gravity according to the Preliminary Reference Earth Model (PREM).

The points of both the most and least gravity are below the planet's surface!

The answer to our previous hypothetical miniverse was wrong. A miniverse with an Earth like mass would have the point of least gravity at the center of that mass and the area of most gravity would be below the body's surface.

To match traditional gravity well depictions Earth's gravity graph can be flipped so that low gravity is up and high gravity is down. Mirroring the graph then shows a path down to the core and back up again. The result is a sombrero gravity well cross section of Earth's gravity. Note the highest point in our gravity well, the point of least gravity, is inside of the planet and not on the edges. The edges will approach zero gravity, but will not reach it.

This also means the least gravitational time dilation in close proximity to Earth would be at the center of the planet. As long as no other body interferes with the gravity well this holds true as far out into space as the body is old.

To match the traditional 3D depiction, Earth's gravity well would looks something like this.

Gravity wells are not just dips, they are shaped like sombreros.

Wednesday, March 21, 2018

It's JOSE, not JWT (A Pedantic Complaint)

You might have heard about JWT's, but the JWT specification is just about claims as a payload inside of a JWS, which is apart of the JOSE specification. 

In a small series of RFC's, 7515 to 7519, JOSE (JSON Object Signing and Encryption) is defined as a standard that uses cryptographic functions for communication across applications using JSON.  JOSE is an effort to modernize a hodgepodge of standards and provides a basic framework for future cryptographic applications all while using the popular and familiar JSON standard.  JOSE isn't alway concrete with its recommendations and instead sometimes prefers basic guidance for applications seeking a starting point.  JOSE is a needed and welcomed addition to a long history of web standards published using the Internet Engineering Task Force RFC process.  
JOSE is broken into two specifications.  JWS (JSON Web Signature) is for signing and integrity protection.  JWE (JSON Web Encryption) is for encryption.  For some undivined reason JOSE's introduction resulted in much of the web referring to the whole standard as "JWT" (JSON Web Token), a small section of the larger standard.  Perhaps it's because of the novel way JOSE was popularized on the web with cookies.  JWT claims used in cookies can free servers from remembering session information by trusting the cryptographic signature, originally signed by the server, provided by the client.  This novel usage is a small part of a much larger standard, and even this usage highlights the power of JWS.  There's nothing special about JWT in a generalized case, as it is simply just a payload.  
Perhaps the name "JWT" is popular because of the way JOSE introduced itself in its RFC's. The first RFC in the series concerns JWS and doesn't really explain what JOSE is.  Instead the reader is told a JWS header is called a "JOSE header" and that everything else, its payload and signature, is called a "JWS payload" and a "JWS signature" as one would expect.  Why would only the header be named "JOSE"? The reader using these clues is initially left to infer JWS is a subset of JOSE.  In later RFC's JOSE clearly becomes the given name for the standard as a whole.  For example RFC 7520 is titled "Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)".  This is also made evident in drafts which include JOSE in the name as it is the name of the IETF working group.  This information is lost to readers new with the final publishing.  
Now back to JWT, a JWS or JWE encapsulates JWT.  The JWT specification notes that JWT's are just claims in a JWS.  
   JSON Web Token (JWT) is a compact, URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JSON object that is used as the payload of a JSON
   Web Signature (JWS) structure or as the plaintext of a JSON Web
   Encryption (JWE) structure
JWS is the real star of the show for most web applications, and all these pieces fit together under JOSE.  

Friday, March 16, 2018

Mormons, Polygamists, and Evangelicals: My Experience with the iWorks Scandal


I worked for Jeremy Johnson in Utah. He stole millions from people by charging customers for "free trials".

Mormons, Polygamists, and Evangelicals: My Experience with the iWorks Scandal

In late 2008 I moved to Ephraim, Utah in the Sanpete valley for a few months one year after graduating from high school.  
I lived in the second story of a coffee shop caddy-corner from Snow College in what was once an old polygamist house. To quell any doubt of its history, the owner loved showing guests a false wall in a bedroom revealing a secret space, furnished with a small wire bed, where a polygamist hide wives during US marshal inspection.
“It’s Mormon forbidden but good!” the owner would jest pitching a cup of coffee. The shop was run by a determined group of evangelical Christians aiming to provide diversity in the homogeneous Mormon environment to the young student population attending Snow. There were Mormon church buildings every few blocks in the Mormon grid-planned city and the coffee shop was one of the few non-Mormon religious groups in the region. I was personally ex-Mormon having determined Mormonism wasn't for me at a young age.  I had become acquainted with the coffee shop years previous by chance on a MySpace page.  I moved to Utah with the hope to learn more about Christian ministry targeting Mormons as I had hoped to eventually to enter ministry.  My Mormon childhood had exposed me to enough religion to think ministry was my best chance at having a positive impact.  I planned on finding work and being apart of the coffee shop efforts.  This "internship" would be apart of my schooling.


Ephraim sits an hour south of Provo with large stretches of open valley and farms between. During my first trip to Provo a few large white buildings caught my attention.
“Why are there hotels out here in the middle of nowhere?”
“Those aren’t hotels,” a friend replied. “Those are polygamist homes.”
Once a friend whispered at the Walmart in Ephraim while pointing their nose inconspicuously at the checkers, “They’re all married to the same man”. I later confirmed with others that indeed this was true.

Gays, Google AdWords, and an Illegal Alien: The iWorks Whirlwind

As a broke 19 year old, a call center selling Internet products was the most appealing employer in the Sanpete valley.  After a short interview I was hired.  They noted my Coloradoan accent was perfect for the job.  My calls were related to Google educational products.  
My first shock came shortly after being assigned a desk. I was at the end of a row and only had one person next to me.  
“Next week is my last week”. The young woman who sat next to me said. “They found me.”
I raised my eyebrow with obvious confusion. “They found you?”
“I get deported next week. I have no family in Mexico, I don’t know Spanish, and I’ve lived here my whole life. All I’ve ever known is Sanpete. I don’t know what I’m going to do.”
I never would have guessed.  She was a perfect, respectful, hard working American.  She told me she was brought to America when she was only a few months old.  She was gone the next week and was perhaps 20 years old.  
Many of the managers were apart of a relatively liberal polygamist group in Manti with some managers even married to the same men. Many of the workers were a part of another polygamist group in the valley. There were also a few Mormons and a handful of non-Mormon Christians.  
The first week on the job my supervisor told me, “Management likes you Zach. I overheard one of the managers saying, ‘His voice is as smooth as butter.’” My metrics were outstanding.  I was a young kid who had loved everything computers and spent most of my free time playing with Linux.  I was able to manage their workflow intuitively and my metrics showed it.  
Later, in a private closed door review, that same manager said with a thick Sanpete accent directly to me what she had already told my supervisor, "Your voice is as smooth as butter.  If I wasn't married I'd snatch you right up."  She was at least a decade or two older than her sister wives and perhaps double my age.  "Was she just horny?" I wondered.
The overseas call center was on a Filipino island and we were told that not only were all male Filipino employees gay, but in fact, the whole island was gay.  Was this the biased perception of the polygamist management or a poor retelling of a poem by Sappho of Lesbos?  The truth stayed hidden as I never dared to ask our Filipino coworkers directly, but they were very friendly and overjoyed to talk with Americans.  
“Hi sir Zach! It’s so good to hear you, sir Zach!” I would hear ecstatically many times a day. We would laugh at their cheerful insistence on always calling us "sir".  


One of my roommates was Gabe, an ex-Mormon like me. We meet before during my previous summer visits to the Sanpete Valley and always enjoyed his cheerful company.

Gabe was in need of work, but had terrible seizures from neurosarcoidosis at night.  Sleep proved a difficult burden to overcome in holding a day job. He had been let go from various places around the Valley who saw Gabe as flaky and undependable.  As his roommate I knew the grimmer reality of his condition.
iWorks was in desperate need of help and I asked them to hire Gabe.  I explained his condition and they were willing to deal with the unexpected absences Gabe’s seizures caused. “Show up when you can and we’ll pay you for that."

Scandal Uncovered

One day a Filipino employee transferred a call to me. Normally there were no issues as we would issue refunds liberally, but this particular customer insisted on speaking with a supervisor despite a full refund. As English speaking Americans, most American positions were “supervisors” of the overseas staff.
“Here’s the link to the signup page”, I said to the customer.  
They responded, “No. this was not the link. I signed up on a different link.”
"This is the link I have sir."
“No, you are wrong. I read everything thoroughly. The page promised not to charge my credit card” They said stressing every syllable. “Please, find out what they are doing and stop them from hurting people.” They paused, searching for words.  “Get to the bottom of this and stop them from hurting more people.”
I was moved by the genuine plea for correctness so I started to search.
iWorks had given us a large list of links to all the company’s products. During training I had also seen a map of “target regions” which was the contiguous United States with the glaring exception of Utah itself. iWorks did not sell products to Utah, and appeared to exclude Utah from its AdWords campaigns. I had always thought this was strange, so I searched Google for terms related to our products over a VPN to outside the state. Google products, health, supplements, fitness, weight loss training, and “acai berry”. I quickly found an ad for one of our product pages.
He was right. The page iWorks showed to customers was totally different from the links given to employees.   The only way we would have discovered this was by using an Internet connection outside of the state.  
Nearly identical to the links given to employees the customer facing page explicitly promised to not charge after the trial period. The page the employees were given said exactly the opposite. The link the company provided in emails and to employees was purposely deceitful. Management had been purposely deceiving employees with false pages which we were then giving to complaining victims. Even more concerning, from my workstation I could not access the URL, but it worked fine over the VPN. They were purposely blocking links inside the building and perhaps from IP addresses in the state. Even if a customer had sent us a link, employees would never have a way to view it, and would assume the customers were wrong. No outside emails were allowed.  There was little chance an employee could ever see a screenshot and even then, how would they know it wasn't doctored?
I immediately reported this to my supervisor, wrote an email to management, and quietly spoke with the trusted friends I had in the office.
“I’ll issue refunds to everyone who calls in!” Gabe exclaimed when I told him my discovery and showed him the links.
“You'll probably lose your job, Gabe.”
“I don’t care, this is wrong. I’m giving everyone a refund that calls in. I won’t let them cheat old grandmas like this!”
I was happily stunned at Gabe’s fidelity. This was the only job Gabe could hold in the valley, and he didn’t give it a second thought. He refused to do anything wrong. He refused immoral compensation.  There were others in the call center that felt the same way.  
One of my other friends was not so gallant.  “I can’t lose this job. I have to provide for my wife. I’ll just do what I’m told and trust that it’s okay with God.”  I was disgusted with his appeal to God to bless  willing compliance. He was able bodied, mobile, and could find work elsewhere if it came to that.  It was a final blow to a strained friendship and was a stark contrast to Gabe’s intrepid commitment to justice.  This friend was one of the reasons I had been living in Utah hoping to learn more about ministry.  Without a strong sense of morality, I didn't desire to work with them on any future endeavor.

Cover up

I got a message from my supervisor the next day. “Management wants to see you.”
“It’s been fun.” I thought as I entered the manager's office.
“We’ve been impressed with your performance Zach. We are promoting you and giving you a raise, a bonus, and making you a supervisor trainer over one of our new programs.” My mouth dropped. I had only been there a few weeks and they were planning on promoting me?  Did they not notice the volume of refunds we were giving?  Our meeting was short, and as I was leaving, she remarked, “Oh and one more thing, about your email, we’ve fixed the problem, thank you for bringing it to our attention. It was a mistake from one of our old, out of commission sites. We’ve taken it down, and we'll be sure that we'll make it right with the few customers affected who signed on from that page.”  I checked that night at home, the secret pages I had found were removed. Just maybe it was a genuine mistake.  My new duties removed me from working with customers or product links directly and I wondered if this was the reason for my promotion.   Regardless, if they tried it again, I would stay vigilant.  
In a couple weeks iWorks release a new acai berry product. Again, I searched Google for terms related to our products over a VPN.  Again, I found landing pages purposely omitting charge information and promising customers that they would not be charged.  The copy distributed internally that had been given was the exact inverse with explicit information about credit card charges. Again, employees could not access customer URLs from inside the call center.  This was definitive. These pages were new for the new products. This was the final nail in the coffin. They knew exactly what they were doing. They were purposely lying to their customers and charging millions.  
I told everyone that would listen to me in the call center and showed them printouts of my proof.  I wrote another email to my previous supervisor and CC’d management and I turned in my resignation.  I felt like I had little reason to stay so I left Utah in the beginning of 2009, moving back to Pueblo, Colorado, my home.


I regret not whistle blowing, but as a 19 year old I didn’t understand the full depth of iWorks deceit. I didn't know whistle blowing was a thing. I didn't know what they were doing was illegal as they had the blessings of the banks and credit card companies.  I only knew what they were doing was morally wrong and I wouldn't be apart of it, just like Comcast's attacks on net neutrality.   Thankfully, Jeremy Johnson, the owner of iWorks, was rightfully sentence in a federal case in what is being called the “biggest political scandal in Utah history”.  I hope he's removed from doing any harm for a long time.  
My friend Gabe, 31, of Ephraim, Utah, passed away unexpectedly on October 15, 2014 from complications with neurosarcoidosis.  I will never forget Gabe's commitment to doing the right thing in face of the vacuous unknown.  

Friday, February 9, 2018

Do not use git's built in gpg signing until git uses something other than SHA-1

If you trust SHA-1 and think it's secure then this post isn't for you.

If you think SHA-1 has been weak for years, is not sufficient now, and is dangerous moving into the future, this post is for you.

Git's online documentation describes how to sign a git commit.
$ git commit -a -S -m 'signed commit'
The massive elephant in the tiny git security room is that SHA-1 is no longer considered secure, and has been considered weak for a long time (about 13 years).  Bruce Schneier warned in February 2005 that SHA-1 needed to be replaced.  Git development didn't start until April 2005.  Before git had started development, SHA-1 was identified as needing to be deprecated.

When signing a git commit using the built in gpg function the project is not rehashed with a secure hash function, like SHA-256 or SHA3-256.  Instead, gpg signs the commit hash directly.

And yes, this commit hash is still a SHA-1 hash.   It's not signing the result of a secure hash algorithm.

A signing algorithm is only as good as its weakest point.  Just because something is signed doesn't magically make it secure if the underlying hash algorithm is insecure.  Worse, if a secure hash algorithm, like SHA-3, hashes the result of an insecure hash algorithm, like the git commit hash, the result is still insecure.

To make signing git code secure, the SHA-1 hash should be discarded and everything must be rehashed with a secure algorithm before signing.  This however is not yet standardized in the git world.  Anything one does securely will not be relevant for existing git infrastructure.  Go ahead and sign your code using something secure, your square peg won't fit into git's infrastructure.  Anything secure will need infrastructure over and above git to ensure security.

Git is moving to support secure hashes, but it's not adopted yet.  Even when it is, it will take time for the infrastructure to catch up.

So what's so bad about signing a SHA-1 hash?  If an attacker finds a collision they can have two copies of a repository, a good version and a bad version both with the signature's blessing. Google's security blog has better examples, but for simplicity:

              SHA-1 ( good code )     = hash123
              SHA-1( hacker code )   = hash123

If the hash "hash123" is signed with with git's built in gpg functionality, not only is the signature valid for "good" code, but it could be valid for "hacker" code.  Developers on the other side of the wire must have systems above and beyond git that prevent such attacks.

A malicious agent can commit a "good" version of a repo, wait until the commit is added to security sensitive repos, and then push the "bad" version.  Bingo.

With specific commit hashes you cannot verify the the version you are building in production is the exact same code as the one a security team audited prior to release without trusting systems external of git.

Alternatives?  Don't use git's built in gpg signing functionality.  Instead, compress your repo and sign the resulting file manually.  Anyone on the other side of the wire will need to familiarize themselves with this process, manually verify, or use a tool outside of git to verify.

Friday, December 22, 2017

Cross pricing of cryptocurrency causes a money multiplying effect like fractional reserve banking

Efficient markets maintain cross elasticity of demand and cross elasticity of supply.  In addition to these forces, reliable cryptocurrency exchanges have established trusted cross pricing among cryptocurrencies pairs.  This cross cryptocurrency denomination results in a money multiplying effect in the cryptocurrency market.  

By either directly pricing a particular cryptocurrency in other pairs, or by increased liquidity readily accessible to anyone with a computer, bitcoin, ethereum, and other cryptocurrencies are increasing cross priced with other cryptocurrencies.  This cross pricing is causing the cryptocurrency market to become more elastic relative to its underlying fiat demand.  

For example, a hypothetical $20,000 purchase of ether could raise the entire cryptocurrency market by $100,000.  Buying $20,000 of ether has a price inflating effect on bitcoin as bitcoin's value is somewhat priced in ether. By the time arbitrage is performed to absorb the purchase of ether, bitcoin's price relative to ether may outrun the utility of arbitrage.

Cryptocurrency markets now experience a sort of money multiplier effect, not through banks inflating the money supply by supplying customers loans, but through cross price action outrunning arbitrage.

Cryptocurrency market value is now less tied to value derived from fiat base money, which in this case could be thought of as liquid fiat money actively available for use in exchange of cryptocurrencies.  Instead, a particular cryptocurrency value is more tied to this cross pricing.  The larger this fiat base money supply, the much larger the cryptocurrency market value becomes.  

State issues fiat has not been sufficiently divisible for such usage, causing price stickiness thanks to its indiscrete nature, but cryptocurrency's divisible properties allow "money creation" merely through division and cross pricing.  

Bitcoin's decreasing liquidity, compared to a lopsided liquidity of fiat, may have helped spur the sudden explosion of cryptocurrency value.  Bitcoin's decreasing liquidity due to unresolved technical issues helps increase cross pricing money multiplier effect.  Holders may not have time to sell before  markets reprice other assets, which are then in turn pricing bitcoin itself.  This illiquidity may have caused a feedback loop in cryptocurrency.  When purchasing however, services like Coinbase allow relatively quick purchases, a lopsided purchasing liquidity power of fiat relative to illiquid bitcoin selling.

This may also mean there could be extraordinary downward swings in value as markets adapt to this illiquidity.

Regardless of hypotheticals, cross pricing further removes bitcoin's value from being tied to fiat.  Cryptocurrency is becoming a more closed system as internal cross pricing increases and external fiat pricing decreases.

Monday, September 18, 2017

"Should I buy cryptocurrencies?" And other cryptocurrency questions

As bitcoin and ethereum appear frequently in the news, I've been getting a few questions about buying cryptocurrencies.

Here's a short primer on my outlook. I am not an investor and this is not investment advice. Buy at your own personal total loss risk.

Should I buy cryptocurrency?
If you have any interest in technology or finance and if technology plays more than a marginal role in your life, then yes.  Absolutely, emphatically, yes.  It's a great learning experience and certainly the future of money.  

After you buy a little bit, play with it. Send some to a friend. Buy something online with it. Give someone an extra tip or give someone a paper wallet loaded with $20 worth. Have fun with it!

Familiarize yourself with cryptocurrency first before making any significant purchase. Cryptocurrency is meant to be used, so go buy some stuff with it!

Do a little research. Google it, read wikipedia pages, browse various forums like reddit, and dig around. One hour of your time might just change the rest of your life, or could just help you be more informed the next time you see CNBC talking about bitcoin.

If you a 90 year old senior that has trouble using a TV remote, then no, you should generally not buy cryptocurrency.

Where do I buy cryptocurrencies?

If you are American, I would use Coinbase to purchase.

I don't recommend trading, but if you insist, use GDAX or Gemini to trade.  There are many other exchanges.  

There is the security problem of storing your cryptocurrency, and this problem can be significant. If you are not going to be in charge of your holding's security, which will be 95% of the general public, then the organization listed previously are among the most trusted American institutions.  I would be okay with leaving small amounts of coins on these exchanges.

If you are going to be in charge of your own security, then you can use an ethereum wallet to store your coins.  Use Google to find the ethereum wallet and be vigilant of scammers. Be mindful, cryptocurrencies are generally immutable meaning "once it's gone, it's gone!" If you are prone to "getting hacked" or are afraid of getting hacked, keep your coins on a service you trust. Be warned, many services have gone belly up in the past although the ecosystem overall is maturing.

How much should I spend?

Do not spend more than you're willing to lose completely.  Cryptocurrencies are still young and not all the bugs in the ecosystem are worked out yet.  The unexpected will happen, and that could mean the complete devastation of particular cryptocurrencies.

That being said, the high prices are an indication of market confidence, mine included.

If you are buying more than minimal amounts, I would use dollar cost averaging over a long period of time.  You can use Coinbase to set up "recurring transactions", which will withdraw from your bank account monthly or weekly. For example, you could spend $20 a month on a recurring transaction to buy cryptocurrency.

There are dramatic ups and downs, but those who have played the long game have all done very well. I've personally bought no more than I can afford to loose.

I own cryptocurrencies because I believe in cryptocurrencies. I have philosophical, moral, and political reasons for my holdings, you may not. Don't be greedy.

What cryptocurrencies should I buy?

In my humble opinion, ethereum.  I sincerely believe ethereum is the future.  All my other holdings are purely speculative.  Ethereum is the only coin with serious fundamentals for the future.  Ethereum is easy to use, nearly universally known, possesses superior technicals, it's faster, it's cheaper, and ethereum is building a more open ecosystem than bitcoin. I think just as a currency with no other use, ethereum is far more promising than bitcoin. Bitcoin also has a lot of infighting and huge technical issues with no solid solution in sight. Ethereum's singular vision is more true to bitcoin's original mission than the groups currently controlling bitcoin development.

I think there's a coming sunset on bitcoin dominance. Even this year bitcoin has lost significant market share to competitors like ethereum. I plan on writing more about bitcoin's flaws in future blog post. Regardless of my personal feelings, bitcoin is still the most trusted, oldest, and universal. There are mounting technical problems that bitcoin isn't handling well while needlessly polluting our environment through proof of work. Ethereum has been faster to adapt, grow, and address issues head on. Ethereum's vision is much clearer and applied than bitcoin's acolytes who are ever the philosophical armchair saints.

I think litecoin is overpriced and maintains minimal utility.  I also recommend against participating in ripple as it is not a cryptocurrency. I perceive it's marketing in the space as mostly fraudulent since it was designed to be centrally controlled.  I can offer my thoughts on other projects, but my opinions are only just opinions.

Research, read, and learn on your own.  Every 6 months or so I would reevaluate your holdings and make adjustments as you personally feel comfortable.

Saturday, August 19, 2017

Nine points for defining stateful systems.

I also talk about state in context of HTTP in another blog post.  Here's my blog post about that too.  

Reminder by liftarn

What exactly is state? Wikipedia says: 

A program is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the state of the system. 
[I]nformation about previous data characters or packets received is stored in variables and used to affect the processing of the current character or packet. This is called a "stateful protocol" and the data carried over from the previous processing cycle is called the "state". In others, the program has no information about the previous data stream and starts "fresh" with each data input; this is called a "stateless protocol".
In casual conversation with programmer friends, there always seems to be confusion surrounding stateful protocols and applications.  Programmers learn early about state while reading programming books, but we sometimes fail to see how it applies to the real world.  So here are 9 points to help in defining stateful systems.

1. A stateless application can be written on top of a stateful protocol.  A particular stateless application might be able to ignore stateful components provided by a stateful protocol, but this may not be possible if a protocol requires specific stateful mechanisms.

For example, there are many old school games hosted on websites with no game saves.  These applications are stateless and every time the URL is reloaded, the player starts over in the game.  No state is remembered even though the website might use http cookies for analytics or advertising.  The game simply ignores stateful information provided by the browser over http.  

2. Inversely, a stateful application can be written on top of a stateless protocol.  In this case stateful applications must supplement the 
utilized stateless protocol with a stateful mechanism.  It shouldn't be difficult to create stateful applications on top of even primitive protocols.  

Additionally, sometimes a stateful application can ignore protocol stateful mechanisms and use its own. This happens in the real world frequently with legacy applications when security or performance needs do not fit legacy protocol offerings.  Seasoned engineers are sure to have seen many hacks and protocol abuses designed to get applications to work as needed.  

JOSE's JWT for cookies is a great example of using public private key encryption as  stateful mechanism.  Just because a server doesn't store a particular piece of information doesn't mean it can't maintain state!  JWT's allow servers to "remember" information by being "reminded" by the client, as long as the server remembers its own public keys which are then used to verify signed messages.  This looks different from traditional stateful cookies, but no where in JOSE cookie usage is there a hint of statelessness.  

3. A stateless protocol is still stateless even while delegating state to other protocols.  This is the philosophical approach of HTTP/1 which originally delegated state to external mechanism and thereby maintained stateless purity.  But don't be confused! HTTP still used stateful software stacks, such as stateful protocols like TCP or stateful components such as cookies.  HTTP's explicit deferment of state to the outside is what allowed early HTTP versions to maintain its claim of statelessness.  

4. An agnostic or optionally stateful approach is best defined by majority usage. It's mostly meaningless to talk about state if it's entirely up to individual applications.  But this rarely matches reality.  Most protocols are used by diverse applications consistently statefully or statelessly.  When it comes to state, why split hairs when majority usage is usually overwhelmingly biased?  Instead, shouldn't we refer to the overwhelming majority? 

Programmers sometimes love being pedantic and pointing at edge cases, but most protocols are only used in very specific ways.  Applications using a particular stack of protocols will utilize these protocols statefully or statelessly consistently.  

For example, almost all web applications use cookies, meaning the vast majority of web applications are stateful.  There are no web applications I use on a daily basis that are not stateful.  To say, "web applications are stateless" is absurd.  

HTTP is almost always used statefully via extension of cookies.  If one is to talk broadly of HTTP being stateless, why?  Why refer to statelessness while modern real world use cases are majoritively the opposite.  It's mostly useless to talk of HTTP being stateless other than to make the distinction between core features and the dependence of those features on stateful mechanism.  

Moreover, cookies are a long established in the HTTP specification as cookies extended the original standard. Early HTTP revisions, which are now ancient in protocol terms, cited cookies as the stateful mechanism, acknowledging cookies as a part of the HTTP standard.  Is it really fair to say HTTP/1.* was entirely stateless when state was added in this era?  I would argue the introduction of cookie killed "stateless http".  HTTP has been stateful since the introduction of cookies into the HTTP standard, and the march of adding stateful components didn't stop with cookies.

I have yet to work on a restful API's or other backend uses of HTTP where rate limiting, authentication, or other mechanisms requiring state isn't considered.  

5. A protocol requiring state is stateful.  This should be obvious, but this seems to be an issue from time to time.  

If any "itsy bitsy teeny weeny" necessary part of a protocol is stateful then I consider the whole protocol is stateful.  It's black and white, no 50 shades of Grey, and no ifs, ands, or buts.  

6.  An opinionated protocol or application that favors state is almost certainly stateful.  This is an edge case, but I mention it to demonstrate the dominance of stateful protocols and applications.  

Protocols that are opinionatedly stateful, although perhaps optional, are best described as stateful.  
A protocol designed to be used efficiently with state is stateful.  The conservative stance must agree with the protocol's guidance.  

7.  Stateful components pollute their supersets.  Statefulness works itself up from the smallest components
 to the largest.

I could diagram a system like this:

protocols ⇒ applications ⇒ application stacks ecosystems

Stateful components confer their statefulness to larger supersets.  At any point in my chain, if there is a stateful component, all larger superset will be stateful.   The same is not true for stateless components as stateless components do not confer statelessness to stateful system.  Once a system requires state in any component at any level, the system as a whole is stateful.  

Yes, an individual application in an application stack might be stateless, but if you mentioning this to a programmer friend in your team, it is almost certainly to highlight it's dependence on other stateful components.  My JSON http api server might be stateless, but without a stateful database it's useless.  

Compare this to a biological cell.  Biological systems larger than any individual living component can be said to be "alive".  The point of distinction is at the level of the cell, where "living" is no longer an appropriate classification.  Sure, there is pedantic grey space among biologist, but the conservative stance is the cell is this fundamental unit for large living biological systems.  Organs are alive because cells are alive.  Organism are alive because organs are living.  Colonies are alive because individuals are alive.  When I eat sugar, sugar does not confer it's non-living state to my living body.  That would be silly, but so too is expecting statelessness to confer statelessness to larger stateful systems.  

8. Complexity and security begets state. Concerning c
omplexity versus state, gains in protocol performance are almost achieved by defining more complexity.  It's difficult to make stateless protocol stacks performant.  Security too requires state.  

A protocol requiring state is the the norm for any sufficiently complex system.  There are many capabilities only possible with state.  State is an early stepping stone to larger and more complex systems.  Only simple systems can squeak by and remain stateless.  

Your best performance and security benefits will almost inevitably require state.  As a protocol stack or application stack becomes more complex and performant, state is certainly guaranteed to emerge.  

Which brings as to the final conclusion:

9. Statefulness is the norm for mature systems. Almost all everyday applications are stateful.  Statelessness is uncommon and the exception, usually reserved for immature systems or individual subcomponents.  

The world is full of stateful applications.  Almost everything is stateful!

Statelessness was more important when computer resources were limited.  In modern systems where resources are plentiful, the distinction is much less useful.  

Defining a stateful system is simple.  Is any part of the system stateful?  If the answer is yes, then it is stateful.  It's that simple.  

Fore more real world examples see my post on HTTP/2 and state.