# Utility Coin Valuation

Cryptocurrency valuation has been a hot topic since the earliest days of Bitcoin, and has only become more controversial with the introduction of tokens and ICO (Initial Coin Offerings). Some investors see ICOs and the resulting tokens as potential Ponzi schemes in the making, though others believe ICOs herald a new era in Venture Capital. So which is it?

As always, the truth is somewhere in between.

In my view, the controversy is largely due to a lack of agreed upon coin valuation models. These would be standards which consider specific factors of a coin offering and enable an easy, apples-to-apples comparison, untarnished by one’s emotions or beliefs. The primary challenge is that such models and methods have yet to be developed, an issue which will certainly be addressed as the coin economy matures.

In the meantime, I’ve tried to compile a model of my own. This is my attempt at coin valuation based on fundamentals. Consider it more of a brain dump than anything formal or extensively researched.

Let’s say that you’re invited to take part in an ICO by Amazing Diapers, a company which plans to offer premium diapers at 1 ADC (Amazing Diaper Coin) per pack. A pack of equivalent Pampers diapers is sold for \$30 USD. Does that mean that 1 ADC has a potential value of \$30 USD?

If 1 ADC entitles the owner to receive one pack of Amazing Diapers and equivalent diapers are sold for $30 USD, then you might think that’s obviously the value of the coin. The reality is a bit more complicated. Let’s consider that for a minute. In order to buy Amazing Diapers, the crypto dad has to acquire an ADC coin in order to redeem it for the pack of diapers. ADC can be bought during the ICO or later on coin exchanges. In either case, cold hard fiat cash is exchanged for a coin which, in turn, is redeemed for a pack of Amazing Diapers. In other words, ADC are a special kind of currency, which makes them subject to so-called monetary theories and the famous Fisher equation for money supply. For our purposes, the Fisher equation could be written as follows: $$Coins\ in\ circulation * Coin\ value = { Unit\ Value * Volume\ Sold }.$$ $Unit Value * Volume\ Sold$ represents the total economic value of all coin transactions. When more transactions occur, the demand for a coin increases, driving up the value of all coins equally. The formula can be rewritten to derive the value of single coin: $$Coin Value = { Unit Value * Volume Sold \over Coins\ in\ circulation}.$$ Intuitively, this represents the idea of coin price equilibrium, a situation driven by the scarcity of ADC coins and the demand for Amazing Diapers. The more coins that are in circulation, the lower the price will be. At the same time, the more diapers that are sold (and the more ADC denominated transactions that take place), the more valuable the coins will be. The relationship between volume and the coin’s value is linear, as you can see in the graph above. For the sake of the argument, we assume a 15% growth rate across arbitrary time intervals, but we could have picked any other growth rate we liked as the value is not relevant to our discussion. Irrespective of the growth rate, the coin value eventually approaches the perceived value of a pack of diapers—in our example, that’s$30 USD.

Let’s unpack this a bit more. Potential customers of the Amazing Diaper company need to obtain 1 ADC per pack. How likely are they to pay more than \$30/ADC if the perceived value (or market value) is \$30? Not very likely.

So what happens then?

There are a few possibilities:

• Sales volume drops (i.e. prospective Amazing Diaper customers switch to another brand of diapers)
• The issuer starts offering more Amazing Diapers per coin. This is akin to the process of deflation, or appreciation of a coin’s value.
• The coin issuer released more coins into the market. Depending on the volume of newly released coins, the coin may inflate (experience a drop in value) or stay the same.

The first option is not very interesting—in essence the system reaches a point of equilibrium, with the coin value capped at the value of the underlying good. The growth stops, capped by the equation $Coins\ in\ circulation * Unit\ value$.

For continued growth, the issuer needs to enact one of the two remaining options: deflate the coin or issue more coins. It is remarkable that in either case the issuer begins to act as a monetary authority—the spitting image of the Federal Reserve—with all the associated power and responsibility.

The deflationary path leads to appreciation of the coin’s value. Indeed, one could now buy more diapers with a single coin, raising the value as potential diaper buyers will be willing to pay more for the coin. ICO investors and coin holders are clearly the beneficiaries of this scenario.

But in the final scenario—coin inflation—the issuer is the only beneficiary, leaving investors to twist in the fiscal winds.

Of course, releasing more coins into circulation obviously benefits the releasing party. Coins are sold to market participants for a profit, which is collected by the seller—in our case, that’s the coin issuer. Notice that ICO investors who held their coins see no benefit here and, in fact, may suffer if the coin’s value drops as a result of the additional supply.

An important takeaway from this discussion is the need for sound monetary policy management in order to achieve and sustain steady growth. If a one-time issuance of coins is not followed by active engagement with the resulting market on the part of the issuer, the coin’s growth potential is restricted.

Another takeaway, perhaps the most important of all, is that the success of the coin shifts the leverage away from investors to a coin’s issuers. Initially, when the transaction volume is small relative to the number of coins held by investors, there is little the issuer can do. However, the coins aren’t valuable yet either.

As time goes by and transaction volume grows, driving up the coin value, the issuer gains more and more control over the distribution of the wealth between themselves and their investors. Buyer, be aware!

# Can we trust Gmail?

Gone are the days when E-mails were sent and received from desktops and laptops. Convenience, superior functionality and ease of use drove mass adoption of web based E-mail systems, such as Yahoo, Mail, Gmail, Outlook.com and alike. While benefits of web based E-mail are widely known, very little consideration is given to implications on privacy and security.

Quite often web based E-mail systems claim to be secure based on the fact that the communication between user’s browser and servers is protected by SSL. That is a legitimate claim, but it covers only part of the story and leaves out the big picture.

Let’s say someone sent an E-mail message from their Gmail to dolphin@securedolphin.com. The first leg of communication is indeed protected by SSL and unlikely to be intercepted by 3rd parties. Not so much for the next leg - Gmail needs to locate the server, hosting the mailbox for dophin@securedolphin.com and transmit the message text to that server. And there lies the core of the problem – the transmission is not guaranteed to be encrypted – messages can be hijacked while in transit from one server to another.

It is not unusual for communication between mail servers to be sent in clear text, vulnerable to interception. In a way this is similar to conversation over walkie-talkies – anyone who happens to be listening can possibly hear (or read in case of E-mail messages) the exchange. In case of encrypted E-mail, the unprotected transmission between servers is not an issue, since hijacked messages are scrambled and meaningless unless the interceptor has the secret key, used for encryption.

No matter how secure is the first leg of communication, i.e. the transmission of the message between the device, (desktop or phone) and the web mail provider, the confidentiality of your messages can compromised in transit to the ultimate destination, unless the message is encrypted.

# SSL is fundamentally flawed - Google is the latest victim

Google reported another incident of unauthorized issuance of SSL certificates. SSL certificates are used for establishment web of site authenticity. SSL gives users assurances that the site, they are accessing, is indeed the desired web site rather than a fake, created by malicious 3rd parties.

Successful attack on the Indian Controller of Certifying Authorities resulted in unauthorized issuance of certificates for several Google domains. Individuals in possession of fake certificates can mimic Google sites and lure potential victims to give away passwords, credit card numbers and other sensitive information without realizing that sites are not genuine but rather fake.

The fundamental problem with the SSL is that it's security is is based on trust to limited number of commercial organizations (VerySign, Symantec etc.) who are given means to issue certificates to web sites. In theory, these are highly protected, honest and trustworthy organizations. In reality, if history is of any lesson, trusted certificate issuers are as likely to fall victims of an attack as any other organization (Hello Target and mass leakage of credit card numbers. Curious minds are encouraged to check out the Comodo and DigiNotar story also).

NameCoin as oppose to SSL does not rely on trusted issuers for it's names, but rather employes peer-to-peer, decentralized model. The integrity of NameCoin names can't be compromised by attacks against organizations or individuals, involved in NameCoin. There is no single point of failure. The latest Google incident as well as prior attacks on Comodo and DigiNotar are impossible to execute against NameCoin domains.

SecureDolphin relies on NameCoin for secure storage and exchange of cryptographic keys that can be used for encryption of E-mail and other forms of communication as well as secure sign-on with no password transmission over network. SecureDolphin Chrome extension provides easy and convenient tools for E-mail encryption and decryption right in the GMail window.

# ProtonMail and PayPal saga - continued

I wrote about the ProtonMail before, in connection with PayPal freezing the account, used for collection of Indie Go Go donations. Checking back some time later, I found that PayPal lifted the gate on the account. When pressed on reasons for freezing the account, PayPal blamed a "human error". The explanation looks fishy to me. But, even if it is true, there still is a fundamental problem, a problem, that I've pointed to before:

#### Reliance on PayPal, which is subject to regulation and legislative pressure, is the Achilles' heel that drags down ProtonMail

Think of it this way: even if the ProtonMail account was frozen due to human error, the incidents highlights the possibility for PayPal to do that at any time. No, PayPal, being good citizens, likely won't do that voluntarily. Would they have to freeze ProtonMail accounts if summoned to do so? Would they have to comply with requests from FBI, CIA, NSA or other body? I think that is likely. Do I believe in PayPal's best intentions to protect their clientele, i.e. ProtonMail in this case? Absolutely! However, make no mistake, when the question comes to protection of one client vs. loosing the business or affecting hundreds, thousands or million others the choice is likely to be very clear. Is it possible that PayPal finds itself in under treats to be shut down or comply? Yes. Check out the LavaBit story for a recent account of a company being shut down for standing up and backing it's users

I truly hope that ProtonMail learns the lesson and finds ways to eliminate dependencies on centralized services or infrastructure. Going peer-to-peer is the only viable path...

# Running NameCoin under CentOS and RedHat 6.2

This is a follow-up to the my notes on Compiling NameCoin under CentOS and RedHat 6.2. After the successful compilation, I've tried to start the software and... got a core dump. Running it under debugger quickly revealed the source of problem.

Upon startup, NameCoin daemon attempts to load wallet keys or generate a new wallet if one does not exist (i.e. the wallet.dat file is missing in the data directory, set in the configuration). In either case, it uses OpenSSL to create or load an Elliptic Curve (ECC) key. ECC keys are initialized with certain parameters. Normally, OpenSSL users would use EC_GROUP_new_by_curve_name API call and pass in the unique identifier of the pre-configured parameter set that was shipped with OpenSSL. Apparently, not all OpenSSL distributions are created the same. The version on CentOS and RedHat 6.2 is missing the NID_secp256k1 definition, which results in failure to initialize the key on these platforms.

I've created and submitted a patch, based on ideas and some code from similar patch for BitCoin. However, my patch is still not accepted. Feel free to apply it manually in the mean time.

Obviously, this applies to Fedora also, as I've mentioned in the previous entry

# ProtonMail did not escape the Big Brother!

ProtonMail is the most recent addition to the family of secure communication solutions (there are a few others that I will cover in separate blog posts). According to their web site ProtonMail is fully anonymous and confidential web E-mail system, i.e. Yahoo Mail or GMail but better: they don't have access to your E-mails and don't keep track of users, accessing the service. What can be better! No wonder the ProtonMail Indie Go Go campaign managed to attract remarkable 300K in a month or less since the launch of the campaign. The news broke a few days ago that the ProtonMail campaign ran into issues with PayPal, who handles some of the payments, contributed through IndieGoGo. Paypal froze ProtonMail account and refuses to release accumulated funds. At the same time, contributions made through BitCoin remain safe and fully accessible to ProtonMail. The news highlights an important fact largely overlooked by broad public and, specifically, enthused ProtonMail campaign contributors: no system, solution or tool is secure, safe or anonymous unless it is fully distributed and peer-to-peer. Moreover, the weakest chain defines the security of the overall system. In case of the ProtonMail the reliance on PayPal that is subject to regulation and legislative pressure is is the Achilles' heel that will drag down ProtonMail if not eliminated ASAP! True confidentiality and anonymity are impossible as long as there is slightest dependency on centralized, governed solutions or infrastructure.

# Building NameCoin under CentOS and RedHat 6.2

I am working on a project that runs on CentOS Linux 6.2 and requires operation of a customized NameCoin daemon and client. The first step to customize NameCoin is to build it on the target platform from source. Instructions at the NameCoin GitHub page are quite brief and are tailored to Windows build. There is a bit more at NameCoin Wiki. However, even that is outdated, incomplete and do not quite work for CentOS (and RedHat for that matter). I think they are written for Ubuntu. Here are my notes from tweaking the NameCoin build procedure to yield a successful build of the daemon and the client:
• Install required prerequisites yum install boost-static db4-cxx.x86_64 db4-devel.x86_64. boost-static is an umbrella package that brings in all other packages necessary for compiling against boost. NameCoin build instructions ask to download dependency libraries and place in the namecoin/lib directory. With these instructions there is no need to do that.
• Download the source code from GitHub or do git clone https://github.com/namecoin/namecoin.git
• Open the Makefile in namecoin/src directory and remove the -l boost_chrono\$(LIBBOOST_SUFFIX) line. There is no libboost_chrono.so or libboost_chrono.a library under CentOS as required code/symbols are included in other boost component libraries
• Go to namecoin/src directory and type make
• Enjoy the result!
P.S. The same procedure can be used for RedHat and other derivatives such as Fedora. Further tweaks may be necessary on Fedora. On RedHat this is, pretty much, guaranteed to work as CentOS is an exact clone.