Bitcoin is not Cryptocurrency

“4 Strategies for Investing in Bitcoin”

  1. Don’t

With the recent rise in Bitcoin prices, everyone has taken notice.  Even this guy:

My favorite part of the video I watched recently was when he said: “Ether, or Ethereum, Ethereum is the more scientific name for Ether”

Because of this, I’m getting a lot of questions about Bitcoin, but almost none about cryptocurrency.  People are having a hard enough time wrapping their heads around the technology of Bitcoin that they’re not even bothering to ask about the larger cryptocurrency ecosystem.  They’re also equating Bitcoin to cryptocurrency.  Bitcoin is a cryptocurrency, yes, but Bitcoin is not the cryptocurrency.  This may seem obvious, and indeed it is.  However, people are conflating the price and notoriety of Bitcoin with the tech of Bitcoin, thinking, “since Bitcoin has the highest market cap, surely it must have the best technology, and the most utility, therefore, whatever Jackson says about Bitcoin must hold at least somewhat for the entirety of the cryptocurrency market”, which is patently false.

An example.  Someone recently told me they asked their financial advisor about buying Bitcoin, and he told them it was a ponzi scheme and to steer clear. I think this financial advisor came to the right conclusion, but probably for the wrong reasons.  If you’d have asked him what he thinks about cryptocurrency in general he probably would’ve said the same thing, but that’s because his only frame of reference for cryptocurrency is Bitcoin.  Bitcoin may very will be a “ponzi scheme” (I don’t know if it is or isn’t, so don’t ask me) but that doesn’t say anything about cryptocurrency generally.

But, I’ve also had numerous discussions with engineers who view it the same way.  Many call Bitcoin digital gold, which is one step removed from real gold, of which the famous Warren Buffet has this to say:

The second major category of investments involves assets that will never produce anything, but that are purchased in the buyer’s hope that someone else – who also knows that the assets will be forever unproductive – will pay more for them in the future. Tulips, of all things, briefly became a favorite of such buyers in the 17th century.

This type of investment requires an expanding pool of buyers, who, in turn, are enticed because they believe the buying pool will expand still further. Owners are not inspired by what the asset itself can produce – it will remain lifeless forever – but rather by the belief that others will desire it even more avidly in the future.

The major asset in this category is gold, currently a huge favorite of investors who fear almost all other assets, especially paper money (of whose value, as noted, they are right to be fearful). Gold, however, has two significant shortcomings, being neither of much use nor procreative. True, gold has some industrial and decorative utility, but the demand for these purposes is both limited and incapable of soaking up new production. Meanwhile, if you own one ounce of gold for an eternity, you will still own one ounce at its end.

What motivates most gold purchasers is their belief that the ranks of the fearful will grow. During the past decade that belief has proved correct. Beyond that, the rising price has on its own generated additional buying enthusiasm, attracting purchasers who see the rise as validating an investment thesis.

As “bandwagon” investors join any party, they create their own truth – for a while. Over the past 15 years, both Internet stocks and houses have demonstrated the extraordinary excesses that can be created by combining an initially sensible thesis with well-publicized rising prices. In these bubbles, an army of originally skeptical investors succumbed to the “proof” delivered by the market, and the pool of buyers – for a time – expanded sufficiently to keep the bandwagon rolling. But bubbles blown large enough inevitably pop. And then the old proverb is confirmed once again: “What the wise man does in the beginning, the fool does in the end.”

Today the world’s gold stock is about 170,000 metric tons. If all of this gold were melded together, it would form a cube of about 68 feet per side. (Picture it fitting comfortably within a baseball infield.) At $1,750 per ounce – gold’s price as I write this – its value would be $9.6 trillion. Call this cube pile A.

Let’s now create a pile B costing an equal amount. For that, we could buy all U.S. cropland (400 million acres with output of about $200 billion annually), plus 16 Exxon Mobils (the world’s most profitable company, one earning more than $40 billion annually). After these purchases, we would have about $1 trillion left over for walking-around money (no sense feeling strapped after this buying binge). Can you imagine an investor with $9.6 trillion selecting pile A over pile B?

Beyond the staggering valuation given the existing stock of gold, current prices make today’s annual production of gold command about $160 billion. Buyers – whether jewelry and industrial users, frightened individuals, or speculators – must continually absorb this additional supply to merely maintain an equilibrium at present prices.

A century from now the 400 million acres of farmland will have produced staggering amounts of corn, wheat, cotton, and other crops – and will continue to produce that valuable bounty, whatever the currency may be. Exxon Mobil will probably have delivered trillions of dollars in dividends to its owners and will also hold assets worth many more trillions (and, remember, you get 16 Exxons). The 170,000 tons of gold will be unchanged in size and still incapable of producing anything. You can fondle the cube, but it will not respond.

Admittedly, when people a century from now are fearful, it’s likely many will still rush to gold. I’m confident, however, that the $9.6 trillion current valuation of pile A will compound over the century at a rate far inferior to that achieved by pile B.

I can’t blame Mr. Buffet for not investing in Bitcoin.  However, he’s recently said he was wrong about Google and Amazon.  Buffet isn’t a technologist, he’s a financier.  He also claims he only invests in things he understands.  I don’t blame him, or many other people for not understanding this tech and it’s nuance.

However, I tend to agree with Mr. Buffet, and the financial advisor with regard to Bitcoin.  Bitcoin may very well be a ponzi scheme in as much as gold is.  Bitcoin core is positioning itself as a digital gold, as such, if you don’t think gold is a solid investment, you probably shouldn’t invest in Bitcoin, using the logic given above by Buffet.  But this does not mean that all cryptocurrencies are positioning themselves as digital gold and that you shouldn’t invest in any cryptocurrencies.*

Also, while I’m at it, too many people who haven’t investigated the cryptocurrency ecosystem are substituting arguments against Bitcoin with arguments against cryptocurrency in general.  What may hold true for Bitcoin in an argument does not necessarily hold true for all cryptocurrencies.

Building Blocks

Speaking as a software engineer, we’re trained to crystallize logical concepts, and then use these crystallized logical structures to build more logical structures on top of the existing ones, and with the block chain, we’re doing just that.  Block chain engineers are extrapolating from Bitcoin’s block chain structure, building new things with it everyday.  One of the breakthroughs for me when learning about cryptocurrency was when I investigated Ethereum and saw the inferences made from Bitcoin’s original block chain.  Once this connection was made I started to realize the possibilities were vast, not just internal to the Ethereum block chain as many before me have already stated, but with the block chain concept as a whole.  We’re still trying to figure out which building blocks fit where, which are useless, and which will form the backbone of this new landscape.  But that’s technology.  There will be many more innovations to come, as this technology is very much still in it’s infancy.

Yes, we’re in a bubble

Yes, we’re in a cryptocurrency bubble, and everyone is trying to cash in on the craze.  But this doesn’t mean there isn’t still true innovation and disruption happening in computation in this space.  But also, what’s wrong with a bubble?  Look at the beautiful infrastructure and technology the last tech bubble gave us.  The cryptocurrency bubble is turning heads, just as the dot-com bubble did before it, and luring brilliant engineers into it’s fold due to these absurd valuations.  Yes, a lot of people are going to lose a lot of money, but a lot of people have, and will continue to, make a lot of money, just as they did during the dot-com bubble, and I don’t think there is anything wrong with that.



*note: this also doesn’t mean that Bitcoin’s only use is as a digital store of value, but for the sake of keeping this digestible for beginners, I won’t go there.  In fact, the only reason I bring this up is because I know advanced readers from the Bitcoin community are going to pitch a fit about this.  Yes, most of us understand you’re purchasing access to the btc network, but with all the price speculation it remains to be seen if access to this network is priced according to it’s value.


My First Crypto Paycheck

Here is a fifth post written in my series of articles for ETHLend, an Ethereum based lending start up.  Enjoy!


As some of my followers may know, I write for the Ethereum start up ETHLend. I started out blogging about cryptocurrency on the weekends because it is a fascinating subject and there is always something to write about. I felt the best way to learn about the subject was to try and explain it to non-technical readers. Often, the hardest people to convince of this tech are non-technical readers. The technical readers have either investigated the tech themselves and have made up their minds how they feel about it, or, if they haven’t, they aren’t going to come to my blog for their information, at least not initially. For this reason, a majority of my posts are geared toward non-technical readers (with a few exceptions 1, 2, 3, 4). This was mostly a weekend hobby, but when I heard ETHLend was looking for technical writers to write about the development they were doing I jumped at the chance to get paid for a weekend hobby. I quickly got in touch with Jordan, and we started the discussions with Stani on the ETHLend slack channel.

My “Job”

The majority of my duties involve explaining the breakneck development that the ETHLend dev team is doing in as simple terms as possible, as well as positing thought experiments with regard to where this tech could possibly lead and implementing these ideas in experimental code. This has been an absolutely blast, and has allowed me to approach the decentralized ecosystem from the perspective of a lending platform. It’s one thing to read about a Solidity library and follow someone else’s tutorial, it’s another to actually explore it through concrete use.


One of the most fascinating aspects of working with an Ethereum start up that was pre-ICO, was I got a bit of insight into the world of ICOs that I otherwise wouldn’t have. During my negotiation with Stani before I started writing for ETHLend, we agreed that payment would happen completely in LEND. Since these tokens were pre-ICO, they hadn’t hit any of the exchanges and had no valuation. To put this into perspective, 1K LEND is equal to $150 now, but at the time of negotiation, neither Stani nor I had any idea what these tokens would actually be worth. The ultimate skin in the game.


As crazy as it may sound to some, this is one of, if not the largest, motivators for me to accept the position. I felt I was following the footsteps of many in the crypto community who came before me, like Vitalik Buterin and Andreas Antonopoulos. The legend of being paid in crypto appealed to me.

I also find it fascinating that a protocol can create their own currency which it can use to pay it’s members and sustain itself. This is one of the most important disruptive aspects of cryptocurrency.  Cryptocurrency will be around for a long time because of the fact that an entire digital economy can be built from software.  This gives software engineers an avenue to monetize open source projects.  Which incentivizes more developers to go the open source route, driving the creation of more digital micro-economies.

It’s also ruthlessly free market. If the market decides this token (and therefore the protocol, or software backing it) is useless, then the project dies. This is why my excitement at being paid completely in crypto may seem foreign to some, as there is obviously a large amount of risk involved. An agreement to be paid 100 LEND per word can just as easily be worth $100 as it can $.01 after the ICO.

Thank You

I’ve recently received my first payment of LEND tokens for my writings, and for that, I am extremely grateful to the ETHLend team for all of the hard work they’ve put behind the project and give the tokens value to the decentralized community. I’m grateful at the opportunity to join the ranks of writers to be paid fully in cryptocurrency. I’m also grateful to be a part of this new version of the decentralized economy. Finally, I’m grateful to everyone who’s read any of my material, argued with me, debated me, and most importantly asked questions. Here’s to another year of cryptocurrency!


Buying the Dip, or, using ETHLend as a P2P Margin Trading Instrument

Here is a fourth post written in my series of articles for ETHLend, an Ethereum based lending start up.  Enjoy!


When I first joined ETHLend I brought it up with my coworkers over lunch that I was joining an Ethereum start up as a writer. Being engineers they were intrigued and wanted to know more about the project, the Ethereum block chain, and what problems ETHLend was aiming to solve. I had just finished this article comparing ETHLend with Prosper. So I explained the use cases of ETHLend from that context. We all thought it was an interesting idea and moved on to other conversation. However, recently with the large influx of new crypto investors, and the bloodbath in crypto today, it got me thinking. Perhaps the most interesting use case for ETHLend is the ability to get quick leverage when the market dips, rather than as a decentralized replacement for micro loans.

Good Luck Buying the Dip

I’ve been in cryptocurrency since Bitcoin was $500, so I know, like many of us do, that this extreme market correction isn’t abnormal. With this correction in prices, I’m interested in buying the dip. I knew the dip was coming eventually, so I pre-emptively initiated a transfer from my bank last week. The funds won’t be available in my exchange until December 28th. Good luck buying the dip. Good luck making any sort of agile investments when this is the case.

Indeed, with the influx of new investors, this seems to be the worst news when I break it to them that they probably won’t be able to buy any cryptocurrency for at least another week, and that’s if they’re lucky. I’ve seen people have to sign up to numerous exchanges due to the different KYC laws each exchange abides by in hopes of getting added to even one. Add to the mix, the unique bugs on each exchange’s on-boarding pipelines and the whole thing is a bit of a nightmare for a new cryptocurrency investor, particularly when a dip like yesterday happens.

The Two Week Fiat-Crypto Border

While sitting in the airport yesterday, watching the market correct, and wishing my transfer was complete I started thinking about ETHLend. Maybe ETHLend’s use case isn’t an Ethereum version of Prosper, but rather some kind of internal block chain leverage instrument. With this massive delay of getting funds into an exchange account, it’s almost like there is a two week wide border separating traditional assets and crypto assets. It may be that ETHLend’s primary use case is as an investment leverage instrument for the crypto side of this fiat-crypto border, moreso than transparent lending. Don’t get me wrong, that’s one obvious advantage, but sometimes big breakthroughs are more nuanced than the primary goal of a start up.

An example. The market corrected. Because of this, I’m interested in buying more crypto assets. Tokens have gone on sale. I tell my bank to send funds to an exchange in preparation for my discount holiday shopping spree. Two weeks later my funds arrive…and the stores are all closed.

What if, instead of requesting funds from my bank, which moves at a snails pace (this is why we’re all so excited about this technology in the first place, isn’t it?). I simply place a loan against my current token holdings. Maybe I’m certain Dash will recover within the next month and I’m holding 500 BAT. I request a loan to get .2 ETH, or even better, 125 Tether (ETH seems to be a part of the correction, sadly), which I can then use to purchase the Dash I so badly covet. Let’s say the loan lasts for 1 month. If, as I expect it will, the Dash price recovers, I pay the agreed upon interested on the loan, the lender is happy, and I’m happy because I got my Dash at the holiday discount. If instead, I’m wrong, and after a month the price continues to drop, the lender keeps my 500 BAT as collateral. In either case, I still get my Dash.


Maybe ETHLend really shines as a peer to peer “bank”, with which quick crypto leverage is achieved. It can still have it’s more obvious use case as a decentralized Prosper, but speaking as an investor, it sure would’ve been nice to have been able to buy this dip. I’ve yet to use my LEND tokens on the ETHLend platform, but I know the next time the market corrects, I won’t be heading to my lethargic bank, but rather to ETHLend.

External Price Feeds in ETHLend using Oraclize

Here is a third post written in my series of articles for ETHLend, an Ethereum based lending start up.  Enjoy!

ETHLend is an Ethereum based lending platform that aims to unbank lending and offer blockchain liquidity backed by crypto assets. In short, ETHLend does this by allowing borrowers to put different types of tokens up as collateral for pseudonymous and transparent borrowing and liquidity. While the the idea is simple, in practice, the engineering necessary to provide a rich set of features to the user is non trivial since the ethereum infrastructure is still in it’s infancy. Today we’ll investigate one of the challenges.

Price Feeds

When a user provides a token as collateral to the ETHLend smart contract, the question is: what is this collateral really worth, and who gets to decide this? Is it the lender, or the borrower? or someone else completely?

As an example, perhaps I would like a loan of 10 ETH for my Sunday Lambo shopping. I’m willing to give you 10 DOGE as collateral for this loan. Obviously this is an extreme example, and I would hope no lenders would be willing to take such a laughable loan, however, what about a loan of 1 ETH for 45 OMG?

It becomes clear that we need a way of accessing data outside the ethereum network in order to have an agreed upon standard for fiat, ether, and token values. Rather than letting any one person decide the value, we can allow the market to decide. But how are we going to get this data? It isn’t readily available to the Ethereum blockchain.


Many in blockchain are already familiar with the phenomenal Oraclize service. For those not familiar, a brief explanation from Oraclize themselves:

“Oraclize is a service offering a set of tools and APIs aiming to enhance the power of smart contracts. By providing access to both on-chain and off-chain data, Oraclize allows to find an answer to any query your contract may have.”

Essentially, what Oraclize does, is it empowers smart contracts to access information outside of the blockchain in a trustless way. Want to pay a user ether every time they tweet your hashtag? Oraclize makes this possible. Want to attach a bounty to your stack overflow question? Oraclize makes this possible. The possibilities with the brilliant Oraclize service are endless.

Tying Them Together

ETHLend has developed an Oraclized based smart contract that allows for loans to be requested in USD but transacted on the Ethereum blockchain using the Kraken API for the exchange rate. Internally, ETHLend’s contract keeps the USD/ETH price updated every minute through the EthTicker method. It then exposes this publically to dApp developers through a call to the smart contract’s “ethPriceInUsd” variable. Any time a user would like to create a loan in USD, or even get the exchange rate, this can be readily retrieved and accessible to all ETHLend participants as the agreed upon value. Obviously this contract can easily be extended to any fiat currencies currently trading against ETH, as well as any number of ERC20 tokens as well.

Edge Cases

There are, and will continue to be, a number of different edges cases that may arise in the lending cycle, and ETHLend is continually closing the gap on these. Let’s take a few short toy examples to illustrate how this external price feed comes in handy.

How do we know if the borrower has enough value in the tokens they’ve offered as collateral for a loan? Easy, have the smart contract check the exchange rate for the collateral and the requested loan amount to ensure the borrower and lender are copacetic on the value proposition.

What about when the loan has been filled and the collateral drops or rises in value before the loan is repaid? Crypto is highly volatile after all. With the current ETHLend smart contract, since the loan was presumably created in USD, the volatility of the underlying cryptocurrency is irrelevent. A loan for 500 USD today may involve .625 ETH, and at the time of repayment, 50 ETH, however, as long as the two parties are comfortable treating USD as the pegged currency, they are happy with the outcome. With this new smart contract, they now have the ability to do so, should they choose.


As I said, even a simple concept such as lending on the blockchain is actually fraught with different edge cases. Because of this, ETHLend is always looking out for talented blockchain engineers to contribute!

As we saw, having a way to value currencies in a loan market is of utmost importance for decentralized lending. With Oraclize, ETHLend has this power, and is able to give a much more rich set of functionality to users than it can without Oraclize, making the loan process even more transparent in the process.

How to buy and claim EOS tokens

In a similar vein to my iota purchasing tutorial, today we’ll be walking through a purchase of EOS.

EOS is being touted as the Ethereum killer.  It aims to solve a number of Ethereum’s scalability problems, as well as a number of other oddities associated with Ethereum that we won’t go into in this post.  One of the members of EOS is Dan Larimer, creator of Bitshares and Steemit, which boast two of, arguably, the fastest block chains.  The crowd sale opened in June of this year, and I knew about it but I didn’t invest.  This is because (the company building the EOS network) is very clear that when you’re purchasing EOS tokens you’re effectively receiving nothing.  Yeah, you read that right, nothing.


The way the crowd sale is structured, you’re investing in the company, and they’re building the EOS network, but you have no guarantee of return on investment, or utility of the tokens on the network.  Effectively, can take all of this crowd sale money and go to the Cayman Islands with it and there’s nothing legally anyone can do about it.  It may seem odd that I’m investing in something like this, and as I said, it’s taken me 5 months to talk myself into it.  But, as Dan put it in an interview, he’s already independently wealthy via steemit and bitshares, and doesn’t really need the money.  I also believe is covering their asses for the Howey Test that the SEC uses to decide whether an asset is a security or not.  I believe a lot of the language they’re using is an attempt to circumvent the Howey Test.  Also, they recently released their test net, so they’re building something, which is more than you can say for a lot of ICOs right now.  Finally, I made an alright profit from the recent Bitcoin price rise.  I figure, I can gamble a bit with money that is the market’s and not mine.

I ended up using the crowd sale smart contract to make the purchase, but if I had to do it over again I would probably just buy the tokens on an exchange and register my EOS public key via the smart contract.  There’s already enough complexity going on here, and I think the crowd sale smart contract adds to this complexity for beginners unnecessarily. However, I wasn’t sure how was tracking the Ethereum EOS tokens, or whether exchange tokens would be treated differently.  Anyway, here’s a quick overview of what we’ll be doing and why.

Oh, also, this was the first time I’ve actually been effected by the cryptokitties



We’ll be taking ether from your wallet, and sending it to the EOS smart contract, which has a payout every day, based on the amount of ether that’s been paid into the contract on that day (part 1 of this tutorial).  Once the period is up, you can retrieve your tokens from the smart contract (part 2 of this tutorial).  Finally, before the entire crowd sale ends on June 1, 2018, you must generate your EOS public and private key pairing and map your Ethereum wallet address to this EOS public address (part 3 of this tutorial).

What’s essentially happening here is, EOS wants your capital, but they don’t have a network yet with which to receive said capital, so the most effective way of them getting that capital is through the Ethereum network (Ethereum did a similar raise on the Bitcoin network when they started).  However, they still need a way to map your investment to you so they can pay you your EOS tokens on the EOS network when the crowd sale ends.

1. Buy Ethereum based EOS tokens

First send ether from your wallet to the EOS smart contract.


  1. Go to the EOS website
  2. Scroll down and click GET EOS.  Note that US residents will have to use a VPN as the crowd sale blocks US IP addresses (see the Cayman Island and using an exchange comments in the introduction).
  3. Review the conditions, check all the boxes if you agree and click Continue.
  4. Copy the crowd sale smart contract address for the token distribution.
  5. Go to MyEtherWallet and click Send Ether & Tokens from the main menu. After unlocking your wallet put the copied crowd sale address from step 4 in the “To Address” field and a desired amount you’re investing in the “Amount to Send” field.  Press Generate Transaction and submit.

NOTE: one thing I’ve found from readers of this step is that there is a minimum of ETH that must be sent to the smart contract otherwise the transaction will fail.  That minimum is .01 ETH.

2. Claim the tokens you’ve paid for

Using you can see the current rate of ETH/EOS for this crowd sale round.  You can also see when the current crowd sale period ends.  At which point you’ll be able to claim your EOS Ethereum tokens.


  1. Go to MyEtherWallet and click Contracts from the top menu.
  2. Select EOS - Contribution from Select Existing Contract drop down. The address you’ve previously sent ETH to will appear. Click Access.
  3. Select claimAll from the Select a function drop down at the bottom.
  4. Unlock your wallet and press Write.*
  5. In the modal, leave the amount at 0 and set the appropriate gas limit.

*I had problems with the claimAll function running out of gas (DAMN YOU CRYPTOKITTIES!).  You can also select claim and enter the day you purchased in the smart contract (in my case it was 172).  From here it’s the same steps.

To see if your claimed tokens are in your wallet, add the EOS custom token:

  1. Go to MyEtherWallet and click Send Ether & Tokens from the main menu (you won’t send anything this time).
  2. Look for Token Balances on the right-hand side of the page.
  3. Click Add Custom Token. For the field named Token address, enter 0x86fa049857e0209aa7d9e616f7eb3b3b78ecfdb0. For Token Symbol enter EOS and for Decimals enter 18. Click Save.
  4. After your claim is processed, you will see your EOS token balance by choosing View Wallet Info from the main menu.

3. Register to claim native EOS tokens after the sale ends

The steps here are the same as for claiming the Ethereum tokens except before going to MyEtherWallet you need to generate the keys that will be used on the future EOS platform.

Make sure you claim the native tokens before June 1, 2018 at 22:59:59 UTC.

“Within 48 hours after the end of the final period on June 1, 2018 at 22:59:59 UTC, all EOS Tokens will become fixed (ie. frozen) and will be non-transferrable on the Ethereum blockchain.”


  1. First, you’ll need an EOS key generator. The good news is that @nadejde has one.
  2. Go to MyEtherWallet and click Contracts from the top menu.
  3. Select EOS - Contribution from Select Existing Contract drop down as before.
  4. Select register from the Select a function drop down at the bottom rather than claimAll.
  5. Put your PUBLIC EOS key to the key field.
  6. Unlock your wallet and press Write button.
  7. In the modal, leave the amount at 0 and set the appropriate gas limit.

You can ensure that the mapping from your Ethereum public address to the EOS public address is correct by following these steps:

  1. Go to MyEtherWallet and click Contracts from the top menu.
  2. Select EOS - Contribution from Select Existing Contract drop down. The EOS smart contract address will appear. Click Access.
  3. Select keys from the Select a function drop down at the bottom.
  4. Put your Ethereum address in the address field.
  5. Click Read.
  6. In the string field, you should see the EOS public key you input above, if not, something went wrong.


Again, DO NOT FORGET TO REGISTER YOUR EOS PUBLIC KEY TO YOUR ETHEREUM WALLET ADDRESS! The Ethereum address will be useless in the EOS ecosystem when the crowd sale ends, and the only way will know where to send the EOS tokens is because they’ve been registered in the EOS crowd sale smart contract.

As usual, if anyone has any questions, don’t hesitate to get in touch!

twitter:@sjkelleyjr instagram:@sjkelleyjr email:

I may have some good news coming up pretty soon, so stay tuned! Until next time.

The Internet vs Itself

My writing with ETHLend often has me diving in uncharted technology.  Often I’m doing things that have never been done before on the planet, such as connecting ETHLend to uPort for example.  This gives me a unique perspective into the daily lives of decentralized developers.  At the same time I work for a very large and customer centric tech company.  The mesh of these two perspectives has led me to ponder the following question: Is the first to market advantage of centralized user experience too powerful for decentralized tech to overcome?


Ethereum is often touted as “web3.0”.  It’s true that what decentralized technologies are trying to accomplish are magnificent and gargantuan tasks.  It’s also true that using ethereum and other decentralized software feels like using the internet in the early days of the web.  Back then you often had to do what seemed like mysterious incantations, without much idea as to what they were actually doing.  Obviously most cryptocurrency feels very much the same way, with things like the iota wallet showing no balance (1,2,3,4,5,6) and the DAO hack.  This makes for an easy comparison to the early web, however, I argue that the comparison is a bit too easy.

User experience on the centralized web is miles ahead of where it was originally, which makes it miles ahead of its decentralized counterparts.  I don’t see regular users leaving the comforts of their Mercedes to jump back on the horse and buggy of decentralized user experience.  And, more importantly, I believe that this analogue will always be valid.

This is not to say that evangelists and technocrats won’t fully embrace this tech in much the same way as the early internet was embraced.  This is because most of us understand what’s happening behind the mask of UI and are much more willing to forgive technical mistakes or ineptitudes than the average user.  My concern is not that the tech won’t be adopted, but that the adoption will never grow above a certain percentage of the population.

The Internet vs Itself

As stated above, it’s easy to look to the technological growth of the internet as an example for decentralized tech to emulate. The problem with this perspective is, the internet didn’t have to compete with itself.  The internet competed with print, and I would argue, until the user experience felt effortless, it fought an uphill battle in much the same say decentralized tech is fighting now.  The problem is, the current state of user experience on the internet is so far ahead of its decentralized counterparts, and will continue to outpace the growth of its decentralized counterparts.

Does UX matter?

One could argue that user experience isn’t everything.  The needs decentralized technologies are attempting to fill are not necessarily motivated by user experience (although, I would argue the motivations of a technology should always be driven by user experience, but that’s a different discussion for a different day).  However, in order to achieve mass adoption, a superior, or at least equal, decentralized user experience must be achieved.

Put yourself in a layman’s shoes.  They don’t understand what the decentralized tech is trying to achieve, they just know it is or isn’t working as well as the centralized version, and will therefore go back to the centralized alternative in the case when it isn’t.  Take the case of steemit.  They’re paying people to use the platform, but the UX is lagging so far behind that of reddit that it doesn’t matter.  People still continue to stay on reddit, and, even after trying steemit will return to reddit.

Engineers Are Users Too

This leads me to my final point.  Engineers are users too.  Building good, clean, maintainable software, such as reddit, is a difficult enough job as it is.  Software developers don’t need to make their difficult jobs any more difficult than they already are.  This is exactly what they’d be doing by opting for decentralized tooling.  The current state of affairs with respect to infrastructure surrounding the modern web makes software development a pleasant experience.  The same cannot be said for the decentralized tool kit.  I hope this changes in the future, but I fear that much like user experience, the tooling of the modern web is also so far ahead, and will continue to outpace its decentralized counterparts, that this will never happen.

This is in large part due to the Pareto Law nature of technology.  The decentralized web must compete with the centralized web.  The centralized web is an internet of billions of dollars in capital, allowing it to hire hundreds of millions of software engineers to work on even the most minute detail of its infrastructure.  While the decentralized alternatives have a hundred thousand at most scattered about the globe working for less, and often for free.  Don’t get me wrong, I commend their efforts, and count myself as one, considering I spend my weekends writing about this tech.


With cryptocurrency, however, more and more funding is being poured into the decentralized alternatives, which is why it’s even possible to argue against centralization right now.  This is actually my main motivation for investing in cryptocurrency.  I invest not because I’m interested in buying a lambo, but because I know the only way to spearhead this technology is to put capital into it and see where that takes us.  It remains to be seen if this funding can ever eclipse the centralized counterparts, however.

We’ve all seen these little infographics showing how cryptocurrency actually stacks up against companies like Apple and Amazon.  Granted, this one is dated, but, even with the unprecedented surge in bitcoin price, all of cryptocurrency still doesn’t match Amazon’s market cap.


This is why I won’t be quitting my day job any time soon to join the decentralized army full time.   As an engineer I firmly believe that decentralized technology is a more robust design than the centralized alternatives, but the cat is out of the bag.  Users have grown too accustomed to having their data now.  Don’t get me wrong, the engineering involved in bringing centralized software to fruition is absolutely brilliant, and has taken decades to perfect.  I believe decentralized tech will get there one day.  But when that day comes, the bar for user experience will be moved still higher by centralized technology.







ETHLend & uPort, A Match Made in Heaven

Here is a second post written in my series of articles for ETHLend, an Ethereum based lending start up.  Enjoy!

In my previous write up I mentioned that we would dive deeper into what a possible block chain credit score would look like. Well, in order to have a credit score, you must first have an identity with which to attach that credit score. It therefore seems the most logical place to start in our investigation of credit scoring is identity. Today, we’ll be using uPort to create a loan on ETHLend using our uPort identity. For the sake of brevity, I’m going to assume you’ve followed the steps in the uPort devPortal and have an identity. I’m also going to assume you’re familiar with how ETHLend works.


To start, we’re going to create a quick and dirty node.js cli for illustrative purposes which we’ll use to connect our uPort identity to:

const uport_lib = require('uport-connect');   
const qrcode = require('qrcode-terminal');      
const SimpleSigner = uport_lib.SimpleSigner;   
const Connect = uport_lib.Connect;      
const uport = new Connect('ETHLend Integration', {       
  clientId: 'UPORT_APP_ADDRESS',       
  network: 'rinkeby',      
  signer: SimpleSigner('SIGNING_KEY'),              
  uriHandler = uri => qrcode.generate(uri,{small:true})  
  .then(userProfile => {  console.log(userProfile);  })    
  .catch(err => {  console.log(err)  })

You’ll obviously need to npm install uport-connect as well as qrcode-terminal.

Put the above code into a file (may I suggest ETHLendRocks.js?) and run:

node ETHLendRocks.js

You should see a QR code generated on your terminal. Scan it, and grant your uPort mobile app access to your uPort identity credentials. You should see your uPort profile data logged to the terminal. Now that we have an identity, we can store different attributes about this identity using IPFS and the uPort-registry package.


In order integrate uport-registry we need to do a bit of extra set up to our existing application:

const uport_lib = require('uport-connect');
const MNID = require('mnid'); 
const qrcode = require('qrcode-terminal');
const registryArtifact = require('uport-registry'); 
const Contract = require('truffle-contract'); 
const Registry = Contract(registryArtifact);  
const NUMBER_OF_LOANS = 10; //random number of loans of illustration
var registryInstance;  
const SimpleSigner = uport_lib.SimpleSigner;   
const Connect = uport_lib.Connect;      
const uport = new Connect('ETHLend Integration', {       
  clientId: 'UPORT_APP_ADDRESS',       
  network: 'rinkeby',       
  signer: SimpleSigner('SIGNING_KEY'),
  uriHandler = uri => qrcode.generate(uri,{small:true})  
const web3 = uport.getWeb3();
  .then(reg => {  
    //set the global registryInstance variable to access anywhere in the app
    registryInstance = reg;
  .then(userProfile => {  
    //decode the users address based on which network they're on   
    let addressPayload = MNID.decode(userProfile.address);     
    return registryInstance.set('Open Loans',addressPayload.address,NUMBER_OF_LOANS,{from:addressPayload.address});    
  .catch(err => {    console.log(err)  })

Using the registryInstance.set parameters we can put any sort of financial data we want to store about a uPort identity. We can then retrieve it using the registryInstance.get() method:

  .then(userProfile => {     
    let addressPayload = MNID.decode(userProfile.address);     
    return instance.set('Open Loans',addressPayload.address,NUMBER_OF_LOANS, {from: addressPayload.address});   
  .then(tx => {     
    const subject = tx.logs[0].args.subject;
    instance.get('Open Loans', subject, subject)
      .then(value => {      
  .catch(err => {     
function hexToString (hex) {     
  var string = '';     
  for (var i = 0; i < hex.length; i += 2) {       
    string += String.fromCharCode(parseInt(hex.substr(i, 2), 16));    
  return string; 

Obviously, this can be used to store information about a uPort identity any time they do anything in an ETHLend dApp. How many times they’ve defaulted, how many loans are currently open, and what value they’re for, are a few examples.


To integrate this uPort identity into the ETHLend ecosystem we simply need to create a contract object with whatever contract we’re interested in interacting with:

const web3 = uport.getWeb3();
const CreateLedgerContractObj = () => {      
  let LedgerContractABI = web3.eth.contract(LEDGER_CONTRACT_ABI);
  let LedgerContractObj =;      
  return LedgerContractObj;  
const LedgerContract = CreateLedgerContractObj();

In this case I’ve chosen to use ETHLend’s Ledger contract. So you’d fill in the LEDGER_CONTRACT_ABI and LEDGER_CONTRACT_ADDRESS with whichever smart contract you’re interested in interacting with.

Once we have the smart contract object, we can call methods on it inside the .then() block of the requestCredentials call:

  .then(userProfile => {     
    let addressPayload = MNID.decode(userProfile.address);     
    const usersEthereumAddress = addressPayload.address;     
		makeLoanRequest(usersEthereumAddress, 100);    
  .catch(err => {     
const makeLoanRequest = (address, loanAmount) => {   
    from: creator,
    value: loanAmount,     
    gas: 2000000    
  }, (err,txhash) => {     
    if(err) throw err;           
    waitForMined(txhash, {blockNumber: null},          
    pendingCB() => {              
      console.log('waiting for loan request to be mined...');         
    successCB() => {       
      console.log('your loan\'s transaction hash is:',txhash);       
      incrementIPFSOpenLoanAmount(address, loanAmount);       
      //any other financial data you'd like to track can be get and set here...     
const incrementIPFSLoanCount = (subject) => {   
  instance.get('Open Loans', subject, subject)
    .then(value => {     
      instance.set('Open Loans', subject, value + 1, {from: subject})    
const incrementIPFSOpenLoanAmount = (subject, openedLoanAmount) => {   
  instance.get('Open Loan Value', subject, subject)
  .then(value => {     
    instance.set('Open Loans', subject, value + openedLoanAmount, {from: subject})    

Here I’ve illustrated how one would store the number and amount of open loans made by a uPort identity at the time of loan creation, but any number of metrics can be used and any point in a loaning and borrowing process.


This brings me to my final point. If we’re going to use IPFS as an open, transparent data store, then the ETHLend smart contract is going to need to update the data associated with the uPort identity via IPFS as well, depending on various conditions known only to the ETHLend smart contract. Currently this is not implemented.

If you’re a developer and you’re interested in developing smart contract code, this is a perfect opportunity to make your mark! Check out the ETHLend repo, and see if you can get your pull request merged into the master branch, or, feel free to get in touch with ETHLend via the many social media channels:

uPort is always interested in hearing from developers as well and in fact were instrumental in making this article happen.

Lessons learned from an ICO


A few months ago I dabbled in solidity development.  I’m interested in all things cryptocurrency, and ethereum smart contracts appear to be a very large aspect of the current state of cryptocurrency.  As such, I had no choice but to experiment with the technology.  This experimentation involved using the truffle.js framework to follow the ethereum foundation tutorials.

During initial smart contract development it’s common to use the testrpc client as this speeds up deployment times allowing for quicker code iterations. There is also less complexity in this chain, so less can go wrong and you can focus explicitly on development.  However, given that the eventual goal is deploying smart contracts to the main net, eventually you begin to turn your attention to the ethereum test networks.  After testing my contracts using testrpc my next step is typically to test on the parity development chain, which similar, to the testrpc client has less complexity but is an actual blockchain.  After testing on the parity dev chain, I move to the kovan or ropsten test networks.  At the time the ropsten network was under attack (and looks like it is again).  So my only choice for testing was kovan.


This is where I begin to have problems in my development and eventually moved on to other aspects of technology (I think at the time it was react-native).  I was working through a tutorial to deploy a DAO like smart contract, and everything was going well, until I attempted to deploy the contract to the kovan test network.

When I would deploy via the testrpc client, or even the parity dev chain, the contract would deploy successfully and I could interact with it via javascript.  However, on kovan the deploy would hang, and then after a long period of time, would fail with this cryptic error:

Error encountered, bailing. Network state unknown. Review successful transactions manually.
    Error: Contract transaction couldn't be found after 50 blocks

At the time I didn’t really understand what was going on behind the scenes with regard to addresses and transactions.  I knew that I had to sign the transaction in parity, but I had already deployed on the parity development chain, created two different accounts on the kovan chain, one email verified in order to get some test ether, and had my main net accounts floating around in the parity files as well.  So I tried a number of different key files, unsure of which was correct,  none of them were signing the transaction successfully, or if they were, there wasn’t enough ether in the wallet.

At the time I wasn’t even sure I was barking up the right tree, and given that I wasn’t actually trying to deploy to the main net anyway, I posted to stack overflow, never heard back, and shelved the issue.

Enter the ICO

A few weeks ago I posted about proof of stake, and through this post met the CEO of a blockchain start up.  I ended up proof reading their white paper, and kept in touch during their ICO.  During the pre-sale they were deploying their smart contract for the ICO and were getting the exact same error I was getting months ago.  Since this seemed to be a recurring error rather than a one off issue specific to me I felt this warranted more investigation.

I went back to my original DAO smart contract that was giving me issues and tried deploying it again.  During this time the CEO made a number of observations eventually leading to a successful deployment of their smart contract.

Here are a few lessons to keep in mind when deploying smart contracts to both the main net and the test nets.

Don’t forget to sign your transaction in parity

Since it’d been a few months since my previous test deployment I had to remind myself how to process works.  When you run:

truffle migrate --network kovan

The transaction still needs to be signed by the address set in the truffle.js file for the kovan network settings.  If you forget this, truffle will just wait, and after a very long time finally fail with the cryptic error message mentioned above.

There’s no harm in trying different keys

As users we’ve been trained that after too many password attempts you’ll be locked out of your account.  In my case I had a bunch of different key files for the same address, if I’d just tried all of them eventually I would’ve found the correct one.

Key management is paramount

I wouldn’t have needed to try every key file if I’d paid more attention to what I was doing with each key while creating test accounts.  As an ethereum user, this important, but it becomes even more important as this can introduce inadvertent bugs, adding to the already high cognitive load associated with development.

Make sure you have enough ether to cover the gas costs

I remember this kept coming up while I was troubleshooting the issue a few months ago.  The first question asked in forums was always “what did you set your gas price to?” and “does the signing address have enough ether to cover this cost?”

Usually when you sign the transaction in parity it will allow you to set the gas price at that time, and will show you the current average gas price on the network.

Screenshot from 2017-09-29 19-47-03

Screenshot from 2017-09-29 19-47-20

You can also set the gas price explicitly in the truffle.js network settings.  For example:


network_id: 42,
gas: 4712388,
gasPrice: 25000000000

would set the transaction to use 4712388 gas with a gas price of 25000000000 on the kovan network.

Use the parity transaction viewer

Screenshot from 2017-09-29 19-53-17

This was one of the jewels passed along to me by the CEO that I wasn’t aware of.  Parity comes with a bunch of dApps, and one of them is a transaction viewer.  This allows you to keep tabs on the state of your transactions, as well as view other pending transactions on the blockchain.  I believe this is what led the CEO to the truffle.js gas price file insight.

Use etherscan

At the end of the day, when I finally went to check if my contract deployed successfully on the kovan network, I looked at all transactions made by my kovan address, and some of my transactions from months ago actually made it onto the blockchain.  Truffle uses what they call an “initial migration” and then the actual contract deploy.  Some of my initial migrations made it into the blockchain, but not the actual contracts, until sorting out the rest of the things discussed above.

This lesson is an obvious one.  Always check etherscan.  Although, some times this may add to the confusion.  Since the kovan network was sluggish at the time, it took awhile for my transactions to show up, this coupled with the cryptic truffle error lead me to believe absolutely nothing was happening.


Most of these are trivial to debug, but when combined lead to difficult debugging, add to that cryptic error messages and it can often be difficult to break down what’s going wrong in a systematic way.  But, this is brand new tech, and because of this, if you’re a developer, any help with these frameworks will speed up development iterations and in turn make this tech easier to work with for other developers in the future. parity truffle

That’s all for now.  I’ve recently upgraded my miner to a new beta AMD blockchain driver, so I may pass along this bit of info in my next post.  Until then!

A Beginner’s Altcoin Mining Setup with AMD Radeon RX470s, Ubuntu, and Claymore Dual Miner

In previous posts I’ve mentioned that in addition to researching cryptocurrency, I also mine it.  This set off a small flurry of questions about the process of printing money with your computer.


Today I’ll begin the first in a series of posts about altcoin mining.

Buying the hardware

Before you can do any kind of set up, you obviously have to invest in the hardware.  There is a boatload of information out there.  We set out to mimic the Ethereum miners that currently exist as a baseline and plan to explore other hardware now that we’ve accomplished this task.

With mining, you’re building a computer from scratch.  This means you’ll need at the very least the following parts: a CPU, a motherboard, RAM, a HDD, a power supply, and in the case of a miner or gaming computer GPUs.

The community consensus for a baseline Ethereum mining rig is as follows:

All together, purchasing this gear, with all 6 GPUs the motherboard can handle, will end up costing you about $2000, and should net you a hash rate of around 120 MH/s.  If you mine Ethereum, this will make you around $200 per month, without doing anything, but keeping the miner running (which is actually more difficult than it sounds, more on this in another post).  However, I’d recommend to begin with you only purchase 1 GPU, to test with, making the initial investment only around $1000, but the hash rate only around 20 MH/s.

We came to this hardware consensus by doing a bit of research.  Here are a few resources we found useful during this research:

The OS

I’m not sure how necessary this is, but we had the OS installed on a SSD prior to the hardware installation (mostly because we were waiting for the hardware to arrive anyway).  Even if it isn’t necessary, it was a good way to test the hardware installation all the way through to OS boot.

We’re using Ubuntu as we’re planning on scaling beyond 1 miner and didn’t want to pay the licensing fee for Windows with every new miner.  As we’ll see in future posts, this is nice from a customization perspective as well.

There are plenty of tutorials available online for installing Ubuntu, here’s a link to the official one.  As usual, if you run into any snags during the process don’t hesitate to get in touch!

Assembling the Hardware

Great! All the hardware has finally arrived! now what?

I’m a software developer, so if you’re like me, the computer has always come assembled ready to be programmed.


This is where the resources mentioned above became useful.  We used buriedOne for info on the hardware set up, as well as EVGA’s official video.  If you’re lucky you won’t have any snags.  If you’re not lucky, the problems could be anywhere from a bad GPU, to a bad display monitor cable, to you shorting something with static while doing the install.  If you do have any problems, feel free to get in touch! I’d be happy to work through any issues or point you in the right direction.

The Driver

If you’ve made it to this point, your miner is now booting into Ubuntu, however, since the GPUs aren’t the integrated GPU, Ubuntu doesn’t know how to talk to them.  Because of this you need to install AMD’s drivers.  Since this information appeared to be pretty sparse online, I’ll go in depth rather than linking to other resources as I typically do.

First, I’d recommend you install ssh, as it might be useful to have remote access to the miner during installation in case you have any hardware issues.

Then go to AMD’s website and find the link to the Ubuntu download (AMDGPU-Pro Driver Version 17.30 for Ubuntu 16.04.3​) and download the driver.  Then go to this AMD tutorial explaining how to install the driver.  The steps should work, HOWEVER, during the step

./amdgpu-pro-install –y

We had to add the –compute flag, as such:

./amdgpu-pro-install --compute


Otherwise, on reboot and login, the Ubuntu desktop failed to load.

If you lose access to your mouse and/or keyboard, you can ssh into the miner and run the following command to get them back

sudo apt-get install --reinstall xserver-xorg-input-all


And finally, if you ever want to try a different driver, or have simply had enough with mining, you can run this:



From anywhere in the terminal (it’s added to the path) to uninstall the drivers.

Verifying the Driver Install

After reboot you can run the following command to ensure that Ubuntu is in fact seeing the AMD GPU:

lspci -vnnn | perl -lne 'print if /^\d+\:.+(\[\S+\:\S+\])/' | grep VGA


You should see a line similar to:

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:67df] (rev cf) (prog-if 00 [VGA controller])

For each GPU attached to the miner.


The Software

If Ubuntu is able to detect and use your GPUs, it’s time to start mining some coins!

The de facto mining software for ethereum is claymore’s dual miner so that’s what we’ll use for this tutorial.  This link (starting from Step 5) was immensely helpful for the initial set up, and we followed it as a baseline, but have since experimented with a set up that works better for us.  You can also set up dual mining using this link.

Congrats! now you’re mining Ethereum!  Making money while you sleep!  Printing money with your computer!

In the next mining post I’ll walk you through some software customizations we’ve made to our rig, as well as some explorations we’ve made into hardware alternatives to the baseline system.




Criticisms of Proof of Stake

Oh boy.  What a week it’s been.  My previous post meant to give a brief overview of Proof of Stake for non technical readers seemed to strike a nerve.

To start, I think people misunderstood the motive of the post.  I was simply giving a brief technical explanation of proof of stake for non technical readers, and some readers seemed to interpret this as support for proof of stake.  I’m a software developer.  I don’t care about the moral or ethical implications of power consumption or immutability.  I’m purely interested in the mechanisms, and I’ve yet to find someone who doesn’t agree that the casper protocol isn’t at least interesting, which is why I blogged about it.

As some of my readers know, one of the main reasons I post is to partake in the discussion that ensues afterwards, and there was a lot of it.  My previous post was on the frontpage of /r/blockchain for two days as well as /r/ethermining for a day and a half, which is great because these were my target audience in writing the post.  However, I also posted on a whim to /r/btc and /r/ethereum where it stayed on the front page of controversial for an entire day, which in my opinion is also great.  I wasn’t expecting the feedback I received, however this is exactly my motivation for writing.  I would like to thank everyone who took the time to read and provide feedback.  In this post I’ll spell out some of the criticisms of Proof of Stake that I left out of the previous post (again, it was intended for a less technical reader), as well as some new ones that I’d never considered until now, thanks to my readership.

External/Internal Staking

It seemed the major criticism people levied against proof of stake was that the staking was internal to the system rather than external.  /u/jps_  makes the point concisely:

“Proof of Work has something physical at stake, namely the electricity necessary to probably solve the puzzle. In essence, the bits in the network are secured by activity outside the network: someone has to generate that electricity. This results in a stable equilibrium, because in order to compromise the bits in the network, one must expend considerable external energy. The laws of thermodynamics make it very difficult to profit by consuming energy”

I don’t buy that external staking makes proof of work superior.  If we assume a free market economy, I should be able to exchange my money for electricity or cryptocurrency.  Obviously markets aren’t rational and the price of a cryptocurrency or the price of electricity isn’t what it should at the particular time that I make this trade of cryptocurrency to electricity, but that’s a discussion for a different day.  The point I’m making is, technically, the $300 of cryptocurrency I bought is of equal staking value to the $300 of electricity I “staked” to mine the cryptocurrency at the moment I did both.  We can discuss the volatility of electricity prices vs cryptocurrency prices, and decide one is a more stable form of staking than the other, but the fact remains that $300 of electricity is equivalent to $300 in cryptocurrency at the time of mining, and it would therefore take an extra $300 more to perform a 51% attack in both cases.*

One argument you could make is that the ethereum casper roll out is premature.  If the market cap of the ether being used to stake is less than the cost of electricity miners are putting forth to mine ether, then you could make a case that this is raising the probability of a 51% attack.

Another argument is that once the electricity is used, it’s on the blockchain forever, while the staked cryptocurrency can easily be converted back into fiat.  As we saw with the casper smart contract from the previous post, the funds are locked for a certain number of blocks.  This may not be completely irreversible as in the proof of work case, but this number can be altered to suit the needs of the blockchain (which, depending on your opinion may or may not be a good thing, see below), to include irreversibility if need be.

Nothing to Stake

I introduced this briefly in the previous post, but didn’t go into much detail, as I didn’t want to confuse non blockchain readers.  Since it’s already been introduced, I’ll assume everyone is familiar with the problem and why it exists.  I mention that casper purports to solve this problem by use of an arbiter smart contract which penalizes malicious validators.  One argument that kept coming up was concern that a malicious chain could be built and hidden from the rest of the validators and then shown at an opportune time.  Casper handles this by locking the validator funds inside the smart contract and receiving “tattle-tell” transactions from validators in the event that evidence for malicious behaviour is found in previous blocks.  One of these malicious behaviours is not betting on a chain, another is betting on the “wrong” chain.  These are both actions that would be necessary to build this “hidden” chain, and since they’re penalized, you’d run out of ether far before you could pull the attack off.

Rather than discussing this particular case (many others were brought up, and many more will follow I’m sure**), the point is, this smart contract can be altered to ward off any sort of malicious proof of stake behaviour that may arise in the future.


This leads us to perhaps the most damning criticism of casper: the fact that casper’s proof of stake involves a smart contract that acts as the arbiter of the validators.  There is no clear analogue to this in the proof of work context, it simply doesn’t exist.  It’s obviously a single point of failure, as well as an attack vector, and, depending on your perspective of the blockchain, a terrible case of centralization.  One point continually driven home in my discussions with /u/Erumara was his/her reluctance to support something so complex compared to proof of work.  And I have to admit, I do agree that proof of work is much simpler than every proof of stake solution I’ve seen proposed.

However, as /u/naterush1997 points out:

In both cases, there is “centralizing” code – in that it is code that everyone relies on. However, the Casper contract being public means that we have the benefit of seeing if there is some fatal flaw and/or bug. In the case of the attack on PoW described above, this would be impossible, as the attack described is indistinguishable from someone having a ton of computing power.

And even if it is overly centralized, I don’t think the technology shouldn’t still be explored.  Obviously there is a large difference in opinion between the bitcoin and ethereum community in this regard, and I intend on exploring these differences in a future post.  For now, let’s just say the ethereum developers are more willing to take concrete risks with their software even if it ends badly. and in fact, I agree with this strategy.  It’s one thing to pursue an idea simply for the sake of it (as in the case of pure research), it’s entirely different to have millions of dollars at stake in the pursuit of an idea.  This is part of what got me into cryptocurrency.  This mixture of direct financial skin in the game of all parties involved (investors, users, developers) and interesting technology can’t be found anywhere else in the world.


One of the best outcomes from the post was this Andreas video /u/dietrolldietroll passed me.  He makes the External/Internal staking argument, but at the end of the video (at around 42:56) when pressed by a question, he says that both proof of stake and proof of work can coexist in the market due to their different use cases.  I’d say that sums up my opinion of the matter fairly well.  As I said before, tech needs to crash and burn to move forward.  I’m not saying proof of stake will be a catastrophic failure for ethereum, but even if it is, it will be a success for the blockchain movement at large.

I received a bunch of criticism (bunch of haters man) in /r/ethermining for an off hand conjecture I made about proof of stake privacy coins, so I intend to fully rectify this in my next post.  Until then!

*After considering this idea during my writing I came upon a new idea.  If it’s true that bitcoin is defended directly by the cost of electricity used to mine coins, could the sum of all electricity used up to block A be considered the true “value” of bitcoin at that block?

**For example, what if a validator never checked in to the smart contract, and is therefore never penalized, then finally showed up, having rewritten the entire blockchain to look much more attractive to the rest of the validators.  They’d need 51% of the currency to pull off this attack, but I believe using the casper smart contract, even this might be possible to defend against.


EDIT: /u/jps_ in response to my argument against external staking:

If you buy $300 worth of Electricity and use it to secure a PoW network, it buys a finite time/amount of security. After the expenditure, the electricity is consumed and there is no more security. The only residual value you hold is the rewards earned along the way. These rewards cost you an extrinsic $300 that is not returned to you. This creates an objectively extrinsic value of the reward generated in return for security: basically, the reward is worth the expenditure in electricity generated to consume it.

If you take $300 and buy ETH and stake it, you can stake that $300 for as long as you want. Whenever you cease participating in securing the network, your $300 in ETH is returned to you, in addition to your rewards from staking.

Therefore, when you started staking you had $300 you exchanged for ETH. You finish staking and you hold ETH you can sell for $300. Plus rewards. Your net extrinsic expenditure is zero, and your net gain is the staking rewards.

So PoS is a value tautology. It creates something at no external cost, which has a putative external value greater than zero.