2017-12-18

The next wave of ICOs

About half a year ago, SEC released an investigative report concluding that DAO Tokens were securities. Since then there have been a number of high profile cases reinforcing this classification world-wide - UIP, LLToken, CCC, and HMS had to issue refunds to the ICO purchasers in ChinaProtostarr closed up shopREcoin and DRC World were charged with fraud and so on.

On one hand, the future of ICOs may be looking grim, with the law enforcement making it harder for various projects to raise money by issuing tokens. On the other hand, the new classification of (some) ICOs as securities might be one of the best things that has happened in the space lately. We might be on the bring of a new wave of ICOs, and here is why...

Historical waves


Long-term bitcoiners might start to see some pattern in history. Early on, we had the pioneering invention that was Bitcoin. After a few years, it became somewhat successful, earning its early adopters some hefty amount of money. We then saw a few other projects pop up saying "I too would like some money". We then saw first a trickle of new coins appearing, altering the Bitcoin codebase slightly, and then an entire wave of thousands of altcoins doing the same, tweaking the parameters and claiming they are better than Bitcoin, therefore they should get the money Bitcoin gets.

We then saw a new wave come in. Coins that were generally not mined, but created and pre-sold to raise the money the team needed to build their product. Mastercoin, Ethereum, etc. Soon after, once a few high-profile projects have made bank, we saw a repeat of what happened before - a large influx of projects also doing an ICO in a "me too" mentality.

It is rather likely that the next wave of altcoins / ICOs will follow the same trends - starting with a trickle of trail-blazers, following with a wave of followers.

ICO Securities and the next wave


For awhile now, you could see a number of ICOs skirting the line of being a security or a utility token. Perhaps giving a wink to their pre-purchasers - "of course you should not expect a profit, but you know we're just like that other ICO that made such great ROI. We're not promising ours will do the same, but you know...". Maybe they tacked on some functionality to have an excuse to call themselves a utility token - "this token will be used to pay for ads to display to our users. It only has a utility value of those ads. You should definitely not speculate on the token representing a share in the platform we're building" or something like that.

Now, with the SEC report, it seems that some ICO projects are taking things a bit more seriously. The grey area between a utility and a security token has become less of a safe harbour. We can expect ICOs to take a firmer stance on what they are. On one hand, we will have token ICOs staying far away from being a security to avoid the extra compliance burden associated with that, but on the other hand, we will see some new ICOs emerge - ICOs that fully embrace being a security and go all-out.

If you're already aiming to be a security and do all of the due diligence associated with it, you could drop the song and dance of utility from your token. We might see tokens that represent shares in a company, tokens that represent rights to dividends and so on, rather than trying to pretend they are tied to some specific functionality of a utility token.

More importantly, by embracing the due diligence of being a security, those tokens might attract the more traditional investors. Companies could do ICOs instead of IPOs, raise money through token presales rather than seed rounds and so on.

This might be the next big wave of ICOs - ICO securities. We will probably see first trailblazers like impak Coin soon, and we can expect the wave to come soon after. We might see a number of people trying to get rich quick, but hopefully we will also see some true innovators creating something new we haven't seen before in the crypto space. I have a few ideas of my own of what those might be, but one shouldn't give away the billion dollar ideas too quickly ;).

Conclusions


In the past, we have seen a wave of altcoins and a wave of ICOs sweep into the crypto world. Due to the recent SEC report, we might soon see a new wave of ICO securities repeat the same cycle, hopefully bringing in a wave of new kinds of investors into the space.

If you're interested in launching an ICO compliant with the securities regulation, perhaps you'd be interested in checking out the new company I work for - https://www.icomplyico.com/ . We're focused on helping new projects launch compliant ICOs.

2017-11-13

The need for universal opt-in replay protection

SegWit2x got cancelled, and with it probably the most heated "battle" in the Bitcoin space thus far draws to a close. There are many lessons to be learned from this ordeal as well as some other forks that are happening around Bitcoin - what constitutes "consensus" in the community, how will the future forks be handled and so on. One important aspect I haven't seen discussed as much currently is the ongoing issue of fork-proof replay protection - a feature that caused some controversy by its absence in SegWit2x and made Bitcoin Gold a laughing stock when they created a bounty for it very close to their forking date.

Strong vs opt-in replay protection


There is an important distinction to be made between strong and opt-in replay protection. When a fork occurs, the former is always on and prevents any transaction on one side of the fork from being valid on the other side of the chain. Bitcoin Cash has strong replay protection for example.

Opt-in replay protection on the other hand is optional - you can create a transaction that won't be valid on the other side of the fork, but you are also able to have a transaction that is valid on both sides.

Strong replay protection is useful when you want to split from the main chain and remain an independent project. However, it can be detrimental when the changes you're proposing are meant to be an upgrade to the current code rather than forking off into a new project. This is why SegWit2x didn't opt to have a replay protection - it was meant to be an upgrade to the Bitcoin project and be the only version used. The only way to achieve that was to make it hard for both sides of the fork to coexist.

Problem with opt-in replay protection


While opt-in replay protection sounds like the proper way to go, there is one important problem to consider - how do you implement it in a way that will apply to all future forks?

In a perfect world, every fork would be carefully maintained and it would make sure to make its opt-in replay protection create transactions only valid on its own chain. However, as Bitcoin Gold and other projects have proven - we can't rely on forks being managed competently. Hence, we need a universal opt-in replay protection, one that is agnostic to any future forks (even those that don't honour any replay protection whatsoever) and creates transactions that will be only valid on one chain.

Universal opt-in replay protection


A fork that splits off from the main project can be caused by any alteration to the protocol. There is no universal way to differentiate between both sides of the fork ahead of time save for one - the blockchain history. You can mimic anything about the code, even pretend to be some different client, but for certain at some points the blockchains will diverge - otherwise we wouldn't be dealing with a fork. Once that is done, the data can be used to implement the replay protection.

If one could flag a transaction to only be valid if a given block hash is present in the blockchain, that would be enough to ensure it will always be possible to safely move coins around on any fork that might occur in the future.

If both sides of the fork honour that flag, only one side will include the transaction in the block. Do this on both sides and the coins will be safe to spend on two sides of the fork.

If only one side of the fork honours the flag however, the replay protection could still work, albeit with some limitations. You would need to create a transaction with the flag on the chain that doesn't honour it. This way the chain will include the transaction in its blockchain, but the main chain will reject it, since it would not recognise the block hash. After the first transaction is confirmed, it would be safe to spend the coins on the other side of the fork.

Conclusions


It is possible to implement a universal opt-in replay protection that will still be effective even if only one side of a given fork will respect its rules. This should be sufficient to protect one's bitcoins in an event of a possible future bitcoin fork.

The proposed implementation is rather simple and elegant. I came up with this idea when contemplating SegWit2x awhile back, but then became pleasantly surprised when I found out someone else already proposed it as a BIP115 a year before :). It's not part of the main codebase yet, but maybe by the time next fork rolls around we'll have something to protect our bitcoins with...

2017-11-05

What is Bitcoin in the light of hard forks?

This year has been one of the more controversial years for Bitcoin thus far. We have already seen a number of important forks happen - SegWit, Bitcoin Cash and Bitcoin Gold, and we're scheduled to witness some other forks soon - Bitcoin Cash doing a hard fork, SegWit2x looming ever closer, and we might even see some emergency PoW change hardfork in response to SegWit2x. Amidst all of that, many people are asking themselves, debating and fighting over an important question - "What is Bitcoin?" (that iconic question).

The power of the name


Earlier this year, there was a small debacle as to what Bitcoin Cash should be called. It seems that some of its opponents wanted to dismiss the fork by calling it "Bcash" to further distance it from the Bitcoin project. It seems the "Bitcoin" name by itself holds value like any other brand, otherwise we wouldn't have so many projects using it:

How many Bitcoins do we have? (source)

In response to Bitcoin Cash being called Bcash, some supporters of that project started calling Bitcoin Cash by just "Bitcoin", and referring to the SegWit side of the fork as "SegWit Coin".

While at the start it might not seem like much, a definition of what "Bitcoin" is and which side of a fork gets to call itself that is really important. Bitcoin is a currency with over 125B USD market cap, a liquid market on numerous exchanges, and countless of projects using it, many of whom would barely be able to follow what's going on in this debate. A fork of Bitcoin, on the other hand, has to start out with nothing and build up that market almost from scratch.

This is why contentious forks are so problematic and why such a simple thing as replay protection is controversial - whoever wins in the fork and gets to call itself "Bitcoin" will be the project that matters, while the loser won't matter anymore. A fork with a hard replay protection is easy to dismiss as an altcoin, while one without is much easier to pass on as an upgrade to the protocol, as Bitcoin has historically never done replay protection (while it seems Ethereum might be getting that as a standard in the future).

So what is Bitcoin, really?


With all of those forks past and future, many people have to ask themselves - "What is Bitcoin, really?". Gavin Andresen's definition has been a good guide so far:

“Bitcoin” is the ledger of not-previously-spent, validly signed transactions contained in the chain of blocks that begins with the genesis block (hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f), follows the 21-million coin creation schedule, and has the most cumulative double-SHA256-proof-of-work.

It might, however, be worthwhile to start drilling down the definition and listing all of the important semantics that have or might be important in the future.

So Bitcoin could be defined as:
  1. A blockchain
  2. Beginning with the genesis block hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
  3. Containing only validly signed transactions
  4. Containing only not-previously-spent transactions
  5. Containing no more than ~21M coins
  6. Following the ~130 year coin distribution
  7. Continuously, publicly mined
  8. Double-SHA hashed
  9. With a difficulty adjustment every 2016 blocks
  10. Mined using a PoW algorithm
  11. Following the chain with the most cumulative work
  12. With a block limit of 1MB
  13. ...

There are many such nitty-gritty details to list and rank. An important exercise for a lot of people is to rank these various features, and in case of a contentious fork - figure out which of those features might be changed.

So for example, if Bitcoin Gold is creating a fork that changes the PoW algorithm and doing private mining for awhile, versus Bitcoin Cash changing the block limit and changing the difficulty adjustment algorithm, we have forks that change the features 10 and 7, vs 12 and 9. Following this ordered list, Bitcoin Cash would be less contentious (which is not to say - not contentious at all) as it alters features lower down the list.

So would Bitcoin be Bitcoin under Script being changed to Simplicity? SegWit2x changing the block size? A fork that changes the PoW? Which part of the fork would be "more Bitcoin" than the other?

Of course, there is more to a fork than just such rules - there is a lot of politics involved, and sometimes a more controversial fork still remains dominant. Ethereum's DAO fork for example meant the "main" chain violated a very important rule - containing only valid transactions, but that side of the chain is still a lot more widely used than the "purer" alternative - Ethereum Classic.

Conclusions


Battling over which side of the fork is "the real Bitcoin" is more than just fighting over a name. It is the battle for market dominance, wide acceptance and legitimacy in the eyes of the laymen. The winner will be the world's best know cryptocurrency, while the loser will be hardly talked about outside of the crypto circles.

Seeing which side of the debate will endure the upcoming forks will definitely be a seminal point in the story of Bitcoin.

2017-10-29

Blockstream vs miners - looking at the incentives around the SegWit2x fork

The past few months in the Bitcoin community have been filled with discussion of an upcoming hardfork - SegWit2x. There have been a lot of people voicing their opinion on the matter of whether that fork should be allowed to pass or not, but today I would like to look at who I believe to be two key players in this debate - Blockstream (opposing SegWit2x) and the miners, the core signatories of the New York Agreement. More specifically, I will be focusing on the incentives both of those parties have when it comes to dealing with SegWit2x.

What is SegWit2x?


SegWit2x was first proposed as a compromise between the various factions in Bitcoin that were trying to solve the problem of blocks being full. It aimed to both enable the activation of SegWit to enable off-chain transactions, and to increase the block size to 2MB to increase the number of transactions that can be processed on-chain. It was to be deployed in two stages - first by activating SegWit in the summer (which already took place), and then by increasing the block size in winter (which is still pending).

Basic incentives for everyone


When examining why people would be for or against a certain change, it is often useful to look at the incentives they have for being on either side of the fence. An incentive shared by every Bitcoin user and company is to see Bitcoin succeed, be used by more and more people and to gain in value. You can occasionally see someone stating the opposite (along the lines of "it's good the price is going down, it will slow the adoption rate so the project will be developed further before mainstream starts to use it", or people wanting to buy the dip in price), but most people that are invested in Bitcoin want to see it grow, that's pretty much a given.

Beyond that, things tend to get murky. You can see some ideologies come into play and so on. But if you focus on SegWit2x, the basic incentive for both sides appears to come down to the good old money...

Incentives of Blockstream and the miners



So with this, we have a clear picture - Blockstream's revenue stream will come from off-chain transactions. Now, let's look at the other side of the debate.

Miners are paid directly in BTC by the blocks they mine. They mint new coins with each block, and they also collect fees for any transactions they include in that block. At the moment the block reward is 12.5BTC, and the fees add up to about 0.5 to 2 BTC on average. Pretty straightforward and as described in the original whitepaper.

So the miners are incentivised to include as many transactions in their blocks as they can, giving priority to those that pay more fees than the others per unit of size.

Clash of incentives


Both sides of this debate get their money from the same source - transaction fees. Blockstream wants more transactions to flow through their proprietary service to collect more fees from institutions and individuals. The miners on the other hand benefit from more transactions taking place on the blockchain - they earn transaction fees only for the transactions that are included in the block and get nothing from off-chain transactions until they come back onto the chain. With finite amount of money flowing through the network, this is a classic zero-sum game - the more transactions flow through your preferred channel, the more money you have and the less money your opponent has.

In an ideal scenario, we would let both of those options onto the free market and let the consumer choose what they want to use. Some would choose off-chain transactions for their speed, others would prefer on-chain transactions for the immutable records, etc. In a truly free market, the best product will win and the market will reach equilibrium. However, one side is currently at a disadvantage.

The size of the blocks is currently fixed at 1MB and SegWit has been activated on the network. This means that the miners have a finite amount of space to work with, while Blockstream and similar service providers don't have to do much to promote themselves - when the consumer will see on-chain transactions being too expensive for them and the blocks being full, they will by necessity make their way onto their platform to be able to transact.

Moreover, SegWit transactions have a smaller "weight" to them, meaning you can put more of them in a block and even go over the 1MB block limit with them.

So we have a company that benefits from the traditional blocks being filled, while also giving preferential treatment to on board onto and off board from its proprietary services, while blocking others from increasing the overall throughput, all for "the benefit of the consumer". This is basically the Net Neutrality battle all over...

Internet access or block throughput, it's all the same in the end...

Dynamics of power


Looking at this only from the lens of money is of course a bit of a simplistic view of things. There is probably a lot more politics, ideology and power in play - SegWit2x is a hard fork to the Bitcoin network being pushed by the miners rather than the traditional core developers. If it is allowed to pass, it will show that they don't have full control over the project and thus remove them from a position of power, while giving the miners more power on top of the computing power they already hold.

Conclusions


If you look at things from pure monetary perspective, the fight over SegWit2x is a fight about where the transaction fees will flow - whether they will be on or off the chain. Increasing the block size will mean more money will be going to the miners, while keeping it low will force more money to flow through SegWit-enabled services, and to a degree, through Blockstream.

SegWit2x is also a struggle for power in the space - who will be able to make changes to the protocol and how things will be handled in the future.

The struggle might be framed in many ways - allowing an average user to run Bitcoin on RaspberryPi, the centralisation of power in the hands of the miners or core developers, an attack on the Bitcoin network, etc. How much of that is genuine concern and how much of it is propaganda from either side it will be hard to discern.

But in the end, it's probably about money and power...

2017-07-11

A mark of one's existence - records in the blockchain

Part of being a human is wanting to leave a mark on the world. Within us lies the deep need to be remembered, in some form, after we die. We see it in the Cueva de las Manos - Cave of the Hands, where the inhabitants left the outlines of their hands painted on the walls as early as 13'000 years ago.

Cave of the Hands

We hear the same plight from Horace some 2000 years ago in his Odes when he states "non omnis moriar" - "not all of me will die". Similarly, to condemn someone to be forgotten was a fate worse than death for the ancient Romans. It was called damnatio memoriae, or "the condemnation of memory".

In our digital age it is perhaps easier than ever to remove someone from history. While it is easier than ever to record what's going on, it is similarly just as easy to alter and distort the events thanks to tools like Photoshop.


Photos can be altered, memories can be called into question, records could be rewritten, and we can end up with the Mandela Effect. Add to it the right to be forgotten, and soon it might be hard to believe any record or lack of it on the Internet. George Orwell would be proud of what we could do to make someone an unperson.

Everything could be subject to change. Everything that is, except blockchains.

Proof of Existence


While working at Factom I heard a great tagline - "It is hard to guess today what lie you want to tell tomorrow". It might be a very profound statement in today's world of digital records - if you can't backdate, alter historical records or the like, you'd better be completely sure how you want to proceed ahead of time.

All of this is of course only possible through the Proof of Existence and the blockchain technology. Only networks such as Bitcoin or Ethereum can be seen as objective records of history anymore. They alone are big enough to be secure from tampering (if you can't 51% attack the blockchain, you can't rewrite the history) and public enough to ensure any attempt at tempering with them will be a publicly known event. Because of that, any data embedded in the blockchain will remain unchanged and hopefully preserved as long as the blockchain persists.

Record of my data


Today is my 30th birthday, and I decided to celebrate with a little experiment.

A few months back I contacted the Personal Genome Project Canada to participate in their research and get my genome sequenced. It has been an interesting experience, and I did find some correlation between my genetic predispositions and the health quirks I've been experiencing my whole life.

During the study I requested a copy of my sequenced genomic data. It was shipped to me on an external hard drive as the files themselves were 200GB. After leaving my computer to crunch the numbers, the SHA256 results was spit out - "de7a8430be51538ebcdd031390e0de3f7cde74a9c88a76e64406e88b6259d4fe". That was the hash of my genetic information - probably the most elegant version of a digital hand print I could find.

After playing with the debug options in BitcoinQT, I managed to wrap it up neatly in the transaction 32a0f8febb0f9f9c7fe1ce9a6b2a59356f443e27186d2e4b5c5a9a3e5e16f4cd, sent from my two favourite addresses - 17TQLZvXjKTrUyRnV9DuQs4RVDgNjUPeXQ, the address in which I received my first coins in 2011, and 1PiachuEVn6sh52Ez7o6Fymvw54qvQ4RBm, my own geeky little vanity address. And so, in block 1597975 (000000000000000000b43bb4162374befa73a882efa6279d87cd3f11548cff59) my transaction was anchored and became part of the blockchain history, along things like the blockchain marriage, a tribute to Len Sassaman, and the infamous Times headline chosen by Satoshi Nakamoto. To the best of my knowledge, I'm the first person to have embedded a hash of their full genetic information this way.

It wasn't my first foray into embedding data into the Bitcoin history. That honour had to go to the illegal number from 2012 that was done as part of my master thesis research.

Larger records of data


Admittedly, the process of saving the data into the Bitcoin blockchain was a bit complicated. Preparing the inputs by hand, making sure the data itself is fairly small, it can all be rather limiting and potentially get expensive with larger amounts of records. Hence why it might be worthwhile to consider protocols that extend the Bitcoin protocol, while still offering the same cryptographic proof of existence. In comes Factom (full disclosure: I work for Factom).

With the intent of storing the same data, I created a new chain with my name and alias - ef020b0dc14223ca454cb69b36143ffbafa8b09c0ff962b18742cd97a02735c9. The hash was anchored in transaction cdeb46cad69c01f79864e20a56cb227b94c9738b79d8291e4181f5cbd9b86f27 that became part of the block 96731 (d8fea7d7df13f0e629817a552719a7e7e9860023313ddaa5fa76ad34d655ace1).

Now, there is an extra step that needs to be taken between here and Bitcoin - the anchoring process. That is performed externally by the an automatic server. It created a transaction bebfc29801239ad254da97b253c864736257143f17e3519e03e05e3761f57a8f that made its way into the Bitcoin block 1598016. And here comes the magic trick that gets us between a Factom transaction into a Bitcoin block, "the receipt":
{
   "receipt":{
      "entry":{
         "entryhash":"cdeb46cad69c01f79864e20a56cb227b94c9738b79d8291e4181f5cbd9b86f27"
      },
      "merklebranch":[
         {
            "left":"cdeb46cad69c01f79864e20a56cb227b94c9738b79d8291e4181f5cbd9b86f27",
            "right":"0000000000000000000000000000000000000000000000000000000000000003",
            "top":"07e5e997757ce1c4e935aecff3e1fb4bb9f7c466329de38ae19c342106283e7b"
         },
         {
            "left":"c48f1c742f8aea8c834b07615776e6c9f79d2300b4e1eb29ea6e295a55823402",
            "right":"07e5e997757ce1c4e935aecff3e1fb4bb9f7c466329de38ae19c342106283e7b",
            "top":"6d423f0c963ce0a9744eec94e07816263b82c1514c048fc43c791e19a44b7458"
         },
         {
            "left":"ef020b0dc14223ca454cb69b36143ffbafa8b09c0ff962b18742cd97a02735c9",
            "right":"6d423f0c963ce0a9744eec94e07816263b82c1514c048fc43c791e19a44b7458",
            "top":"d985f353aa34b1b7f021a30816019eac3cfd486743eb81b63295d12e7aa182f6"
         },
         {
            "left":"76c2296711dfc90eff2cec432b5592155ce13c4bd0f9cc15b01f842994358f35",
            "right":"d985f353aa34b1b7f021a30816019eac3cfd486743eb81b63295d12e7aa182f6",
            "top":"cb75287e2e1b170e5f5dc99ae7b738139305ad822e0c311cbdfb82ab0fa5d31d"
         },
         {
            "left":"3c00225e5d9f6d5e62c2926c02c5c03c31eaa831ee48d6e216dbe3b637125665",
            "right":"cb75287e2e1b170e5f5dc99ae7b738139305ad822e0c311cbdfb82ab0fa5d31d",
            "top":"fd03d8be680bb8c36ba01f224c71160f934c732a42de1c6d1d106b678e0f23a6"
         },
         {
            "left":"fabbd3f11bb85847530a6493361f3654d8617ab82ea3e34ddcc337c976917ec9",
            "right":"fd03d8be680bb8c36ba01f224c71160f934c732a42de1c6d1d106b678e0f23a6",
            "top":"92545cf4f7485731b6ee9007f9d3348759cd2edda60a9e5e7bc6ef2fa4f11cd1"
         },
         {
            "left":"35f75955731e0cfd98653a5979c6e53a0e97cd49ae91b06ec31001a96625666c",
            "right":"92545cf4f7485731b6ee9007f9d3348759cd2edda60a9e5e7bc6ef2fa4f11cd1",
            "top":"4c9d45d122337f6a85084b1492bbd3fe5fcd8a2bbfc71e7bacf283668fa0770b"
         },
         {
            "left":"4c9d45d122337f6a85084b1492bbd3fe5fcd8a2bbfc71e7bacf283668fa0770b",
            "right":"d9d488d0ddc24aae887d86ce094de1579fe10ce06e8f6b8cdb434f45c8d0cdcd",
            "top":"c0ee8f8410515485de6ca7831dcd09856e08ec89799cf90778ea3211b41b4ba5"
         },
         {
            "left":"e327276f2bbfa0bb9dc9d89095abcb0fe7dc3373a31392892099824c89c332a4",
            "right":"c0ee8f8410515485de6ca7831dcd09856e08ec89799cf90778ea3211b41b4ba5",
            "top":"d8fea7d7df13f0e629817a552719a7e7e9860023313ddaa5fa76ad34d655ace1"
         }
      ],
      "entryblockkeymr":"6d423f0c963ce0a9744eec94e07816263b82c1514c048fc43c791e19a44b7458",
      "directoryblockkeymr":"d8fea7d7df13f0e629817a552719a7e7e9860023313ddaa5fa76ad34d655ace1",
      "bitcointransactionhash":"bebfc29801239ad254da97b253c864736257143f17e3519e03e05e3761f57a8f",
      "bitcoinblockhash":"000000000000000000746bcc20463036af6deb09931d78fbd02546042b80f1d1"
   }
}

While it might look like gibberish, it's a simplified payment verification-style merkle branch leading from the transaction hash through the entry block key merkle root, the directory block key merkle root, up to the Bitcoin transaction itself. As the chain of hashes is complete, one is able to mathematically prove that the transaction indeed made its way into the Factom block and got anchored into the Bitcoin blockchain.

The same mechanism could be used to anchor data such as text into the blockchain, for example securing entire blog posts to prove they existed unaltered in their current state at a given point in time. I intend on doing that for this blog once I narrow down the ideal format, but that's a story for another day.

Conclusion


Bitcoin is probably the first, objective, immutable record of history we have. Any data saved into the blockchain will hopefully remain preserved for a long time. It is possible to extend the Proof of Existence into larger data sets without needlessly expanding the Bitcoin blockchain.

2017-05-29

What other cryptos can learn from Ripple

While last week I criticised Ripple's XRPs, we can't equate the whole system to its currency. There are many fundamental features of the Ripple system that other cryptos can learn from. A lot of them are small and obscure to anyone who hasn't had a hands-on experience developing systems on top of cryptos. Luckily enough, that's my speciality.

So here are a few features of the Ripple system that other cryptos can learn from, as viewed by a programmer.

AccountTxnID and Memos


Sometimes you need to send a transaction with some extra data attached. Whether it's an invoice ID, customer number, or some other business-related information, you have some data that needs to go into the blockchain. This will help you keep track of what transaction did what, give some identifiable information as to the origin of the transaction and so on.

Even Bitcoin recognised the need for this feature by introducing OP_RETURN in 2014. Before that, people used to create unspendable transaction outputs that the system would have to keep track of forever.

Ripple already had that at launch in 2012 in the form of AccountTxnID and Memos. The first is a short field, ideal for including transaction IDs and similar short strings. The latter can store a lot more complex data structures - long strings, multiple hex arrays, that sort of things.

LastLedgerSequence


When building a more complex cryptocurrency system, you have to deal with the fuzzyness of transactions before they enter a block. Essentially, when you send a transaction out, you might not know what will happen to it until it either becomes part of a block, or a conflicting transaction becomes part of a block. If a transaction becomes lost in the network, gets stuck in a processing queue, or there is something else wrong with the system, it's essentially stuck in a limbo. It may be confirmed in the next second, it may never be confirmed, or maybe it will take a few hours.

So here's the problem - how do you handle such transactions? You can try resubmitting them if you have the hex representation of them, but that still doesn't guarantee an outcome. You can try double-spending yourself, but then you have two transactions stuck in a limbo. Do you resubmit a different transaction to credit the same person? Then you might accidentally send them the money twice if you're not careful. All of those outcomes are less than ideal.

Here is where LastLedgerSequence comes in. It's a field you can include in a transaction that allows you to specify when a transaction will DEFINITELY fail. You put a ledger number sometime in the future, and if the transaction is not included before that given ledger number, you know for sure it will NEVER be included in a ledger. The transactions are allowed to fail gracefully in a predictable manner.

Data vs Metadata


First generation cryptos are fairly straightforward. A transaction does one thing and one thing only - move money around. If a transaction gets included in a block it means the transfer went through, if it doesn't - it didn't. There are only two outcomes here.

When talking about a more complex system, there will naturally be more possible outcomes. Maybe a transaction got included in a block and it did exactly what it was supposed to. Maybe it got included in a block but failed to achieve anything. Maybe there are different paths it could've taken to get to the outcome, etc.

This is why Ripple transactions have both data and metadata to them. The first shows what a transaction SHOULD do, the second - what it DID do. This allows the transactions to be more complex, while still ensuring that any given transaction call returns all the information relating to a given transaction.

Built-in, dedicated distributed exchange


An efficient Crypto 2.0 system benefits a lot from having a distributed exchange built into it. While some systems like NXT only allow trading a given IOU for its native token, Ripple goes one step further and treats all currencies the same. You can trade any currency for any other, even to the point of undermining the value of XRPs because of it. It is also a very important part of a few other features.

While systems with smart contracts like Ethereum can mimic the functionality of Ripple's built-in exchange, it would be hard to compete with the efficiency of a dedicated exchange logic. As someone who has experience programming a crypto exchange, I can attest that order sorting and matching can be a complex task that would be hard to efficiently execute in a smart contract. Ripple has the strongest distributed exchange that I've seen in any crypto project.

Trades as part of a payment


In a system with multiple currencies, how do you go from having currency A to sending someone currency B? Quite often, you'll have to take that currency to some sort of market, trade it, then use the resulting funds to send the second currency directly. Alternatively, you use some sort of third party to brokerage the deal, take a cut and take its sweet time to get there.

This is not a case with Ripple. A trade can happen as a part of a payment. Sending money from one address to another is just as simple whether you hold the same currency or not. The currencies don't matter, only the value does.


A Ripple payment that can be fulfilled by 4 different currencies

This feature leverages the power of a distributed exchange to its full potential. Everyone has access to the same market and doesn't need to hold more than one currency to transact with anyone on the network.

Atomic, multi-currency transactions


A big issue with transactions that span multiple currencies is the possibility of the transaction failing partially and the funds ending up in some transitory currency. If you're sending USD and expecting them to end up as GBP, you wouldn't want to end up with EUROs. This would be a bad outcome discouraging people from sending more complex transactions.

Ripple solves that issue by forcing every transaction to be atomic. Either the transaction is fully processed, or it completely fails. There is no way to end up somewhere down the middle. Moreover, there is virtually no limit to how complex a transaction can be. You can send out one type of currency, which would take multiple different routes and touching on multiple currencies before ending up at your destination as the intended currency. It is rather remarkable.

The consensus algorithm and predictable block times


Ripple does not rely on a traditional mining algorithm to create its blocks. Instead, Ripple uses a consensus algorithm to issue its ledgers. While the system is more centralised than most cryptos because of that, it solves a lot of other important issues.

First of all, the block times are quite consistent. You know exactly how often they are created and the interval between the blocks is very short and stable. Secondly, the system is more resilient against front running, making the distributed exchange more honest. Lastly, the system in general is less susceptible to market manipulation by the miners - they can't stall certain transactions or oracle data in hopes of manipulating the market and gaming the system.

Conclusions


While the Ripple system has its flaws, it also has a lot of interesting features other cryptos can learn from.

2017-05-22

Counterarguments to XRP value preposition

As some of you might know, I really like the idea behind the Ripple system. Creating a settlement layer based on trust and IOUs, being able to issue any asset easily, working quite well as a middleware layer, incentivising specialisation, creating a singularity of money, all of that is great. The system is not without its flaws however - centralisation of validators is an issue, and so is the token distribution. While both are interesting topics, with the recent meteoric rise in XRP price, I think it's worth focusing on that part of the discussion.

Basics of Ripple and XRPs


Ripple is a Crypto 2.0 system launched in late 2012. It is based on a protocol predating Bitcoin by a few years, known as Ripplepay. As any good Crypto 2.0 network, Ripple allows its users to issue and transact in any currency. It also supports its own native currency - ripples, or XRPs.

XRPs have a few key uses on the Ripple network. They are used to pay transaction fees, and are required as reserves for any address using the network and creating trust lines. All in all, it serves as an anti-spam measure for the network. Moreover, since every account on the Ripple network can accept XRPs, it is also promoted as a bridge currency.

IOUs are user-created currencies. While any address can issue their own currency, most people will be using IOUs issued by gateways. Those will usually be denominated in fiat or crypto. The IOUs can be traded directly on the network, sent from one user to another, and even perform atomic, multi-currency bounces in a single transaction.

There are a few key differences between XRPs and IOUs. IOUs have a counterparty risk - if the issuing gateway defaults, the tokens will be worthless. You can only send IOUs to or through people that also trust the same gateway. The gateways usually charge a small percentage fee on every transaction. IOU transactions are a bit bigger and more complicated, meaning they can cost more to execute. XRPs are their own cryptocurrency, meaning they are not redeemable for anything directly.

Beyond that, the Ripple network handles both XRPs and IOUs identically - both can be traded on the decentralised exchange built into the network, both can be part of multi-currency transactions, both operate at the same speed and they are both highly divisible.

Criticism of XRPs


The main criticism levelled at XRPs and thus also against the Ripple network is the way the coins were distributed. Ripple Labs, the creators of Ripple, created the network with 100B XRPs in it, and no new XRPs were created since the network inception. This is not an unknown practice in the crypto space - a lot of networks premine their tokens. However, the network creators usually only keep a fraction of the tokens for themselves, preselling the rest to anyone that wishes to buy some. Ripple Labs however, still owns about 60% of the originally issued tokens. This raises a few issues.

First, the company could try cashing out and potentially crash the market. It is very unlikely however. Ripple Labs has recently taken steps to promote its XRP market and put the majority of their XRPs into an escrow (then again, the escrow is unlocking 1B XRP every month for the next ~4.5 years, so it could be better).

Secondly, since the network fees are paid through burning XRPs, they essentially enrich everyone in proportion to the amount of XRPs they hold (if 1% of the tokens got burned, the remaining tokens would be worth about 1% more provided the market doesn't change). This means Ripple Labs is essentially earning 60% of all network fees on the network. This probably doesn't amount to much at the current time, but may be more important in the future.

Lastly, the amount of XRPs owned by one company gives it a negative reputation. A lot of people in the crypto space dismiss Ripple outright as "a premined scamcoin" just because of the amount of coins owned by Ripple Labs.

All in all, that isn't too damning really. Ripple Labs appears to be reputable enough not to try cashing out of what appears to be their golden goose. However, they are not the only major players around...

The founders of Ripple Labs, Jed McCaleb, Chris Larsen and Arthur Britto gave themselves 20B XRPs early on. This later came to bite Ripple Labs in the ass. Jed left the team to start his own version of Ripple called Stellar, and decided to sell his XRP stash, resulting in a legal kerfuffle, a settlement, and a schedule for how those coins may be sold. If those numbers are correct, Jed is still cashing out 20k USD per week, and come ~2019, he will be able to cash out 750M XRP (worth ~256M USD at today's price of 0.34 USD/XRP). Not an ideal situation if the money from your network will be going to a former employee building your direct competitor to the tune of a quarter of billion dollars. While some of those funds might go to charity, that's still not an ideal outcome.

Now that we've dealt with most of the issues XRPs had to face, let's have a look at how XRPs fare on their own network.

XRPs vs IOUs


While Ripple the network has to compete with Bitcoin, Ethereum and other cryptocurrency networks, XRPs the currency have another important competitor - the rest of the assets on the Ripple network. Some networks, like NXT or Counterparty, ensure their native token is at the centre of every trade - you can't trade IOUs for one another on those networks. In Ripple, you can transact purely in IOUs all day every day without touching XRPs for anything else than the fees.

This ties to the central value proposition of XRPs - being the universal medium of exchange.

Distributed currency network vs XRP as medium of exchange (source, presentation)

In short, the problem is as follows. If you have many different currencies on the network, you can have potentially a very large number of markets between those currencies (mathematically, twice as many markets as there are currencies). This means you would have to have a lot of market makers providing liquidity to every market. However, if everyone agreed to use XRPs as the common currency, you would only need to make one market per currency - between that currency and XRP.

At the moment, it looks like that is the case - the major markets on the Ripple network are all trading XRPs for the various currencies issued on the network. At the time of writing, 11M USD worth of trades and 88M USD worth of payments have been executed on the Ripple network in the last 24 hours, majority of which were using XRPs.

The main advantages given for XRPs being better than IOUs are:

  • XRPs are acceptable by anyone on the Ripple network
  • There are no extra transfer or trade fees on XRPs
  • XRPs have no counterparty risk

However, there are also some drawbacks to XRPs, even not counting the coin distribution and centralisation.

Just because someone can receive XRPs, doesn't mean they'll want to settle in XRPs. The network just essentially forces everyone to have an unlimited trust line to XRPs, even if they wouldn't want to hold them.

XRPs might be a decent universal currency for people that want to hold XRPs, but that might not be ideal for banks or big institutions. That's why we see networks like Corda, or even Interledger Protocol (also developed by Ripple Labs) that don't rely on a native cryptocurrency gain traction, while the best example of a real-world application relying on crypto token in the middle is Abra. Creating a universal, international settlement currency was the idea behind Bitcoin, and you don't really see banks using it for that cause.

Market making essentially boils down to either trading the currency like any other crypto, or copying the market from another source to offset your trades. The amount of liquidity you could copy with XRPs is small in comparison to the nigh-bottomless FX market from the real world. If you are going to see real-world use cases being deployed on Ripple, it will be more likely to see them leveraging the existing FX markets rather than going through XRPs.

While XRPs have no counterparty risk, they also have no counterparty protection. If anyone steals your XRPs, they are gone. With IOUs, you can still appeal to the issuing gateway to halt the transaction and potentially track down where it was withdrawn to. The IOUs are thus much less of a target.

On a similar note, XRPs are much harder to track, which would make them less appealing from a compliance standpoint. Gateways on the other hand can whitelist and blacklist addresses that can use their IOUs, thus having an easier time identifying anyone that uses their IOUs.

If a value of a given currency changes in value, you only need to adjust the market using that currency. If XRPs were the universal currency against which all of the currencies would be traded, any time the value of XRPs would fluctuate, you'd have to adjust the entire market.

Adding a new currency to the distributed IOU network wouldn't necessarily mean you'd have to trade it against every other currency. You could only start trading it against the most popular currency or a few currencies that are easy to make the market for (say, fiat<->USD, fiat<->EUR). Because you can easily execute multi-currency atomic transactions on the network, connecting to even one other currency connected to the network instantly means you are connected to the rest of the network.

XRPs have no transfer fees attached to them. While is possible for a gateway to issue IOUs without transaction fees (that's essentially Tether's business model, but on another network), perhaps even leveraging some other big crypto like Bitcoin or Ethereum through voting pools, the fees on those IOUs can always be changed. It seems that the network standard for transfer fees is about 0.2%, which seems to be smaller than the spread on XRP's biggest market (at the time of writing, 0.00015086 sell, 0.00015003 buy, giving about 0.55% spread). So it is possible that sending money through a very liquid FX market you would pay less in transfer fees than going through a less liquid XRP market on just the spread.

So this leaves XRPs with their primary role - paying transaction fees and fulfilling the needed reserves. All in all, about 50-100 XRPs per person / account would be enough for a lifetime of usage. That used to be less than 1 USD, and now is about 35 USD.

Conclusions


The Ripple network is a very useful Crypto 2.0 tool. However, because of the high flexibility and value propositions of the IOUs on the Ripple network, they are XRPs' main competitor in its home court. While XRPs are still needed to pay the network fees, most of the remaining value prepositions can be seen as overstated. The recent rise in the price of XRPs appears to be largely relying on market speculation (as is the case for all crypto) and a new exchange coming on the market.

Related links