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.

"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.

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.  

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 complexity 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.

Back from the Dead: After 2+ Years, Suave Men Professional Styling Paste is in Stock on Amazon!

It's back! After being discontinued in 2015, the superb Suave Men Professional Styling Paste is back in stock!

Rumors were Unilever killed the popular Suave's styling paste as its success began eating profits of higher priced Unilever products. Unilever began selling an expensive and slightly tweaked Dove clone after axing the Suave version, but the new Dove version didn't prove nearly as popular.  

Early reviews of the Dove "Sculpting Paste" clone were mediocre as the Dove version included additional perfumes, a more glossy look, and a weaker hold.  Amazon reviewers made it clear that customers would be better off with American Crew than the new, sub-par Dove product. 

Question: How does this compare to Suave's (discontinued) styling paste? I see some notes in the reviews regarding some variation in the ingredients.
Answer: It has a stronger perfume smell and the hold seems weaker. I will be trying the American Crew pastes at this price. 

Another Dove clone reviewer states: 

This is a good product. It was simply rebranded from a Suave product that was cheaper in price though. Depending on where you look be sure to compare the price PER OUNCE to higher end brands like American Crew. Honestly American Crew can cost about the same, a little more, or a little less depending on what store or website you look. Keeping in mind there is only 1.5 ounces in this Dove product so make sure to compare the per ounce cost and not container cost. The fact a Dove product (formerly Suave) is at the same general price point of American Crew is pretty crazy to me. I swear I remember buying this product when it was Suave for under 4 bucks at Walmart. Really disappointed in the price hike and now I believe this to be overpriced.

Early reviews of the newly resurrected Suave are positive:

It's back! I used this all through high school and then Suave came up with a new pomade that I hated. All i can say...it's back and this is gonna be the only one I use!

Personally, I bought a three year supply of Suave when it was discontinued and I'm excited to see that I won't have to switch to American Crew! 

You can see these three products (Dove, American Crew, and Suave) and the reviews included here by searching Amazon for "styling paste".

Happy hairdo-ing!  

Is HTTP/2 a Stateful Protocol?

TL;DR:

• HTTP/2 is a stateful protocol.
• HTTP/1 was not originally a stateful protocol.  
• Your existing HTTP/1 application is probably stateful anyway.

What is a stateful protocol or application?  Go see my other post on state and then come back here.

HTTP/1's Stateless History

HTTP/1 was opinionatedly designed to be stateless long before the Internet was in common use. Work on HTTP was started in 1989 with its first documented version published in 1991, years before the Internet was in the average American home.  The stateless hopes of HTTP/1 were for simplicity.  State introduced complexity that could complicate quick adoption.   In the uncharted waters of the Internet birthing the World Wide Web, it was decided that until clear use cases were known defining stateful mechanisms was excessive.

By 1995 the Internet was booming but before cookies existed websites had a huge issue,  how to keep track of customers with a stateless HTTP?  Since HTTP was stateless, there wasn't a way for customers to "log in" other than each website creating their own session management mechanism on top of HTTP.  

For example, a site could include a unique secret string in all the self referencing links for site. This secret string would be used to track a particular user and ensure that only someone with this secret string could access user account information.  Such an implementation would also need all self referencing web page links for logged in users to reinclude the secret string on every site link in a page.  If a single link didn't include this information a user would be logged out and would need to log in again.  This would require developers to design their applications accounting for stateful links in the entire application, and this user information would pollute every link on every page. What a management nightmare!   There were also usability issues with such an approach.  A browser's URL bar would expose this secret user string to the end user, something the user shouldn't care about.  What if a customer shared this secret user string URL?  It could leak sensitive account information and was an obvious usability and security issue.  

What if a site wanted to automatically log users in? Homepages like ebay.com had no ability to know who the user was. The only possibility was to once again manually log in.  Yuck!

In short, session management in HTTP was a pain. It was obvious that HTTP needed state management independent of this back and forth with stateful URL's.  

1994: Introducing State via Cookies

The stateless HTTP 1 issue was resolved with the introduction of cookies during the Netscape glory days in 1994.  The cookies RFC is titled, "HTTP State Management Mechanism" and quickly cookies became the primary HTTP session mechanism. Cookies  made user accounts easy to create and manage all around the web.  When cookies first gain public awareness in 1996 the media had a frenzy with the privacy implications, but cookies stuck and we use them heavily today.  

For a modern example of cookies, look no further than Facebook.  You cannot log into a Facebook account with cookies disabled (go ahead, try!).  A quick test shows a new login to Facebook uses 23 cookies!  

You've heard it said, "HTTP is stateless", and that once was 100% true as the original protocol itself was specifically designed to be stateless, but in everyday modern practice we use HTTP 1 statefully via HTTP cookies, an accepted extension to the original protocol mentioned in later revisions.

This is all before we even talk about HTTPS, which uses TLS to add state (and security) to HTTP.  

Said again, even though HTTP/1 was stateless in everyday practice we use HTTP statefully. You can consider HTTP no longer stateless with the long past addition of new stateful components.

On to HTTP/2

There's more problems than just user logins with stateless protocols, chiefly performance.  Without session, browsers must make many requests to load a modern HTTP page and each request comes with it's own performance overhead.  As pages grow more complex, browsers make more HTTP requests and applications begin to feel sluggish due to the performance overhead of a stateless protocol.  

HTTP/2 was specifically designed to address some performance issues with HTTP/1 and it accomplishes a lot of this through state.  

So what components of HTTP/2 are stateful? For starters:

• Framing layer as "stream identifier" is stateful.
• Header blocks, as the spec reads: "Header compression is stateful. One compression context and one decompression context are used for the entire connection".
• Opportunistic encryption.

Section 5.1 of the HTTP/2 RFC is a great example of stateful mechanisms defined by the HTTP/2 standard.  I won't detail it here, but another great starting point is the SPDY wikipedia page.  HTTP/2 is a whole lot more than HTTP/1 and most of the new goodies use state.  

Does this mean that you can't use HTTP/2 statelessly?  There's no reason why you can't use HTTP/2 statelessly just like HTTP/1.  Your application can easily remain stateless even while being built on top of stateful protocols.

The difference of HTTP/2 is that unlike HTTP/1, HTTP/2 defines stateful components in its standard, something HTTP/1.0 intentionally avoided.  

HTTP is nearly as old as me, only one year younger, and in that time a lot has changed.  Don't be surprised that HTTP/2 introduced state!

Summary

HTTP/2 is a stateful protocol and that doesn't preclude a particular HTTP/2 application using a subset of HTTP/2 features to maintain statelessness.

Yes, you can have stateless HTTP/2 applications.

No, you're HTTP/1.1 application is probably stateful, even though people may say "HTTP is stateless".

Most of all, HTTP/2 is a stateful protocol, no ifs, ands, or buts.  

Still confused about stateful systems? See my other blog post for nine points in defining stateful systems.

Amazon’s Genius Airborne Fulfillment Centers Mirror the Airline Industry’s Hub-and-Spoke Paradigm

Ars Technica thinks Amazon’s purposed blimp warehouses are “demented”, but Amazon’s drone army has big problems. Chiefly, it’s drones can only fly 15 miles total.

How can Amazon reach millions living outside the 7 mile warehouse radius without doting the nation with expensive fulfillment centers? Unlike Boeing’s 787 Dreamliner, which is ideal for point-to-point travels, drones are far too limited in range. Even if Amazon dotted the nation with small warehouses to accommodate short last-mile ranges, transportation among hubs remains problematic. Amazon must adopt the Airbus A380 hub-and-spoke model, but what could service main trunk routes? Amazon could copy Fedex’s ground transportation and airline network, but slow ground transportation would quickly end same day delivery ambitions. Amazon must move hubs closer to consumers to accommodate limited drones while maintaining fast transportation among hubs.

Costs for drones are also problematic. Flexport points out:

Route density makes today’s last-mile delivery networks extremely efficient. FedEx and UPS trucks enjoy a marginal cost for dropping off one more parcel as low as $2.00. Drones launching from faraway warehouses won’t be able to compete with this efficiency any time soon.

Alternatively, Amazon could release drone swarms in neighborhoods from a self-driving truck, which could be much more efficient than a delivery person going door to door. Using self driving trucks for drone swarm deployment would allow hubs to move closer to a consumer without the need for Amazon to build warehouses every 7 miles.

Amazon also has other ideas, namely the Airborne Fulfillment Center (AFC): Amazon’s blimp warehouse hubs.

Hub-and-Spoke for Drones

AFC’s masquerade as flying drone airports, major hubs that smaller shuttle blimps stock with goods and drones. Shuttles would travel the main trunk routes between hubs and terrestrial warehouses while drones would fly only the shorter last-mile spoke journeys. After departing a hub and delivering, drones would then return to the smaller shuttles blimps which then restock AFC’s.

This solves the problem facing limited drone range while allowing hubs to be closer to consumers. The dreamy blimps also continue Amazon’s trend of turning to the skies over terrestrial infrastructure to quicken deliveries.

Amazon’s hub-and-spoke ambitions aren't radical for delivery service. Fedex has employed the hub-and-spoke model for overnight package delivery since the the mid 1970’s using airplanes.

Although radical flying warehouse may not be the future, what’s certain is the proposed delivery system proves Amazon’s commitment to it’s drone dreams as a last-mile solution.

For more, see the United States Patent and Trademark Office website.