Big numbers don't mean big money

Big numbers don't mean big money

inflation IOU OneCoin premining Proof of Stake Ripple scam

Last week we discussed problems with using really big numbers in cryptocurrencies. This week I'd like to talk about misconceptions surrounding cryptocurrencies with big coin supply as well as inflation in cryptocurrencies.

Coin supply is a joke

Both this and the previous article were inspired by the OneLife Mastermind event, during which the people on stage were gushing about how many coins their system will have and can mine.

"The new blockchain will mine 50'000 coins per minute. [...] I think we are mining about 2'000'000'000 coins now."

In their previous event, they've stated

"Biggest coin out there is Ripplecoin [sic], with 100 billion coins[sic]", and OneCoin will increase its number of coins to 120 Billion to be bigger than Ripple.  

Focusing on the amount of coins you are mining or the coin supply is a joke. It's like praising Zimbabwe for producing 100T dollar notes, or the post WW1 Germany for having so much money you can build toy houses with them.

Market cap is deceptive

A lot of people rely on the market cap to determine which coin is the most valuable and worthwhile. Just have a look at CoinMarketCap. At the moment we have Bitcoin leading the market cap of about $10B, followed by Ripple at $1.2B.

Right at position number 2, we have an issue calculating the market cap - Ripple's available supply is listed at 35B XRP, although its total supply is shy of 100B XRP. If we calculated the market cap blindly, we should take the total supply and multiply it by the current price (0.0035 USD/XRP), which would net us $3.6B, rather than $1.2B.

The market cap is a poor metric for a coin with a highly-centralised supply. As Peter Todd jokingly put it - just mine a large amount of coins, sell a few of them at a high price and you've got a huge market cap.

It would be really hard to create some metric that can measure how valuable a cryptocurrency network is - market cap can be inflated, volume can be faked or hidden, you can't ever know how much of the coin supply is held by a handful of people with a million addresses, etc.

Inflation is not growth

In the past I've seen some deceptive advertising for a proof of stake coin that claimed it was a savings currency. They justified it by essentially saying - "buy our coin, then you can stake it and earn X% per year with it". While on surface it might appear so - if I start with 100 coins and at the end of the year I get 110 coins, then I'm 10 coins richer, right?

That works only on paper. If the market cap for the cryptocurrency remained unchanged and everyone got their 10% more coins, then you're right where you started - you own the exact same percentage of the economy as you used to. The inflation ate your earnings.

In economics, there is an important distinction between nominal and real interest rates. If I take a loan at 5% (nominal) interest rate, but the inflation is at 3%, then I effectively only pay a 2% (real) interest rate on the loan. Each year the principal of my loan has lower and lower purchasing power even if the number remains steady. The same is true for proof of stake inflationary coins - you're not earning anything with them, unless the pace of your earnings is faster than the overall inflation of the network.

A coin will only net you revenue if its equivalent of "real GDP" increases:

If you're not ahead, you're losing money

In an inflationary currency, if your supply of coins is growing slower than the average coin supply, you are essentially losing money. Earning 5% interest in a currency with 10% inflation means you are losing 5% on your investment in an ideal economy. In a real-life scenario, the markets would most likely be swayed a lot more by the speculation on the coin and whatever hype it can muster.

This point usually has low impact on most coins, but it seems to be exemplified with OneCoin's splits and tokens, assuming we would treat the coin as a real cryptocurrency and not a scam. In OneCoin, you can buy different packages that each come with a different amount of tokens and splits. If you buy the cheapest package for 110 EURO you get 1000 tokens and one split, but if you decide to spend 27'500 EURO, you get 300'000 tokens and three splits. This means that not only do you get about 20% discount on tokens when buying them in bulk, buy you can also split them more times (which I'm guessing would give you more mining tokens or something, I'm not sure). Because of this, if you're buying anything shy of the top-tier package, you're already falling behind. I guess that's why you can find a lot of "strategies" for buying the tokens everywhere...

Same goes for the doubling event, wherein everyone's coins got doubled (since 100% inflation equates to 100% growth or something...). If you missed that event, your purchases are only worth 50% of what they would've been before that event in proportion to the entire market. You can't ever catch up.

If you're late, you're paying the early adopters

Unless we're talking about cryptocurrencies with a flexible supply denominated in fiat, anyone adopting late is essentially paying the early adopters. In some cases, that's pretty justifiable - when Bitcoin was still fresh and nobody knew if it had staying power, you needed a lot of people to devote their time and energy into developing the infrastructure everyone relies on today.

However, if you look at something like OneCoin that relies heavily on hype and even pays you in a pyramid-like structure for referrals, you have to be really weary when buying into it.

This is why a lot of people in the crypto world despise premining and fast maturing coins - a few people hold a lot of coins and they get to reap the bulk of the money from anyone buying into the network. When the jig is up, they can cash out and it's the late adopters that get to hold the bags.

If OneCoin was an honest coin, I can see some people getting rich if and when the coin starts getting publicly traded and people can start dumping their coins. As it is now, it is likely that everyone with the coins will be holding the bags while the people behind the coin will be the one with the money.

Conclusions

Coin supply does not matter, market caps can be deceiving, nominal growth does not matter - only real growth, don't buy into scams.

Secondary and debt markets for exchanges

Secondary and debt markets for exchanges

Bitfinex debt hack IOU MtGox Ripple

As discussed last week, Bitfinex has followed through with their bail-in and gave all of their users a 36% "haircut". While not ideal, with the right approach and conviction, this might be a way for the exchange to eventually right their customers. The idea is not new - I recall discussing something similar a few years ago when another big exchange was not measuring up...

MtGox's secondary market

MtGox, the poster child of why one shouldn't trust exchanges with one's BTC, has officially shut down in 2014. However, months before that you could already see some red flags popping up that something was going wrong. MtGox started having some fiat withdrawal problems, and as a result, its market was off by 10+% and ripe for arbitrage. Some people could make a tidy profit churning money around, provided they could get their fiat out of the exchange.

A few months later, the situation got worse - MtGox has officially halted both its bitcoin and fiat withdrawals altogether. However, probably due to some interesting code optimisation, someone figured out that if you withdraw bitcoins straight into a deposit address of another MtGox account, the funds would be transferred without creating a transaction on the blockchain. It looked like that functionality was governed by the "MOVE" API call, rather than "SEND". This tiny functionality was enough for someone to build an entire secondary market for MtGox before the whole exchange went under.

While I can't find any reference to what the site was (EDIT: the website was Bitcoin Builder, as pointed out by /u/samurai321), as the news of MtGox collapse has probably buried it in the sands of time, I remember it being a simple BTC-MtGoxBTC exchange. One could deposit actual bitcoins and trade them for bitcoins owed by MtGox that were moved to the secondary market's address. It allowed some people to get rid of their coins frozen at the exchange and cash out to the safety of the wallets their own, while letting others speculate on whether or not MtGox would be going under. I remember seeing the price reaching a level of 30+% discount on the market, which is fairly comparable to the current Bitfinex scenario...

Decentralised secondary markets

After MtGox collapsed, I haven't seen a similar secondary market pop up anywhere. The closest thing that comes to mind is being able to trade Bitstamp's IOUs on Ripple, which might be an ideal approach for trading exchanges' debt (at least provided the exchange doesn't run into new hacks). If Bitstamp was to go under, you could still trade about 1.5M USD and 2k BTC of its issue on the decentralised exchange nearly indefinitely. Figuring out its USD-USD and BTC-BTC exchange rate against an operating pool could be a clear gaige of confidence in the platform - if there were talks of the exchange recovering, the price might get closer to parity, or go away from it in the opposite case.

At the same time, such a secondary market might be used for something more morally muddy...

Buying one's own debt

Say Bitfinex's tokens were tradable during the hack. Before everyone knew how much was lost percentage-wise, the market would be wild with speculation - you probably could buy bitcoins at 50+% discount, perhaps even at 90% discount if the fear would set in. Now, if Bitfinex was aware of such a situation and knew how much deposits they could actually cover, they could try buying up their own debt for pennies on the dollar before the haircut was to take place. This could allow them to buy off some of their debt at a discount, reducing their obligations to their customers and therefore creating a theoretical profit.

Such a scenario would be highly unethical and I would guess highly illegal, but I wouldn't be surprised to see something like this happen sooner or later in the Bitcoin world. Instead, let's imagine some more ethical approach Bitfinex could act on their current situation...

Slow debt repayment

I'm not sure how Bitfinex structured their token program as I don't use the exchange. However, a good approach to eventually righting everyone would be for them to convert everyone's BTC balance into those tokens. At any time, the users would be able to cash the tokens in and get actual coins, minus the haircut. With each token converted, their obligations would decrease.

The tokens would also be tradable on the exchange itself for actual coins, creating a market for the debt. Anyone wishing to speculate would be able to trade the coins for a value between the haircut discount and 1BTC. The price would have upper and lower bounds, but could fluctuate in between.

If Bitfinex was diligent and set on repaying the debt by eventually buying up all of the tokens, they could publicly declare their strategy of doing so - perhaps a portion of their monthly income would go directly into purchasing the tokens from the market at the spot rate. With every purchase, the amount of tokens in circulation would decrease, thus the ratio of their bitcoins earmarked for buying back the tokens to the actual amount of tokens would increase, making the haircut smaller and smaller. Gradually, the gap between the value of the tokens and the real coins would shrink so much they could convert the tokens themselves straight into coins at a 1:1 ratio and remove them entirely.

In the end, the amount of coins you would get back would rely only on how quickly you need them - you could get them today for 36% off, perhaps get them for 30% off in a year, or get a full amount in a decade. The market would decide what the future value of the tokens would be, and with each month (and perhaps with each trade if some fees were to be maintained for this market), the debt would be slowly repaid.

In the end, this is an optimistic scenario assuming the exchange could earn back millions of dollars worth of coins before the company would go under. Similarly, if you believe the value of bitcoins will go up, the debt may never be repaid - the value of the coins left to be repaid could be going up as the number of the coins would be going down thanks to the increasing price.

One way or the other, it would be a really interesting case study if Bitfinex was to implement something like this...

Related links:

• Avoiding Bitfinex scenarios with Voting Pools
• Full Proof of Solvency - pondering Tether
• Bitcoin historical rallies, halvenings and bubbles

Avoiding Bitfinex scenarios with Voting Pools

Avoiding Bitfinex scenarios with Voting Pools

Attacks Bitcoin Bitfinex hack Ripple theft Voting Pools

This week, a high-profile Bitcoin theft took place at the Bitfinex exchange. The attacker reportedly stole 119'756BTC, worth about 70.5M USD. Those funds were held at a 2-out-of-3 multisignature wallet - one key was held at Bitfinex's server, another was kept by BitGo, and a third was a backup key held offline by Bitfinex. From what the reports say, the hacker was able to get their hands on the first key, as well as the API credentials required to authorise BitGo to process the withdrawal. With no additional safeguards, they were able to drain the hot wallet and land themselves around the number 2 spot of the biggest Bitcoin theft to date, after MtGox.

The scenario is still unfolding, so there are a lot of theories still floating around as to why the situation was allowed to take place. Some have speculated Bitfinex was forced to keep all of their coins in a hot wallet due to CFTC's ruling (as Bitfinex was not a registered futures trading platform), although it seems that the change was made before the ruling. Bitfinex also unveiled a plan for a "bail in", wherein everyone's assets would be devalued by about 36% so the exchange could continue operating.

Since Bitcoin's past seems to be littered with theft, I would like to have a look at one possible solution to minimise such high-profile hacks:

Voting Pools

Voting Pools is an idea proposed by Open Transactions, a Crypto 2.0 platform focused on notaries issuing IOU tokens and other financial instruments. The main issue such systems have to cope with is securing the cryptos, currencies and commodities underlying the assets circulating on the platform - an USD IOU is only useful if you can redeem it for real USD at the end of the day.

The way Voting Pools help secure users' funds is through shared responsibility from competing actors. Multiple exchanges of similar size would group together in a pool and secure one another's funds through multisig and a legal agreement to share responsibility in an event of a loss (be it from theft or one of the exchanges trying to run off with everyone's money). The multisig would be distributed in such a way that any one actor would not be able to control even their own money, and the system being robust enough to handle a loss of some keys (2-of-3, 3-of-5, 4-of-5, etc.).

This setup would make sure that a critical failure of one actor would not compromise the system. Even if one of the exchanges would burn down, get hacked, or the owner would decide to run away with all of the private keys, they couldn't do anything. The other exchanges would take over the responsibility and secure all of the funds to be able to pay all of the failed exchange's customers without suffering a loss of their own funds.

More importantly, however, this solution also forces every participating company to not only police themselves and ensure they have the most adequate security practices in place, but also to look at one another. When your own money is on the line, you will make sure everyone is keeping up with the rest of the pack in terms of keeping the money safe. Since the exchanges would still be competing with one another, they would have every incentive to expose other actors in the voting pool that are compromising the security.

Beyond that the full implementation of Voting Pools also necessitate that the exchanges would open up their transaction logs to one another to make sure everyone knows how much every customer is owed in case of a database wipe or the exchange vanishing from the face of the earth. This is pretty much automatic when it comes to gateways on a public ledger like Ripple or some shared permissioned blockchain, and it shouldn't be too hard to accomplish if an exchange already creates a strict and timely Proof of Solvency. That being said, it is pretty much unheard of for a normal Bitcoin exchange to do that currently, which might make it more problematic.

Having access to a full, real-time set of transaction logs the participants in a voting pool have everything they need to not only be able to settle with every customer in case the exchange goes under, but they can also police the exchange in real-time and raise flags in case of discrepancy. If exchange's liabilities exceed their assets, all withdrawals can be automatically haled until the matter is resolved. Large withdrawals, sudden market crashes and balance changes could similarly raise a lot of flags (to avoid another MtGox scenario, wherein a hacker crashed the market to be able to bypass the $1000/day withdraw limit).

Conclusions

All in all, voting pools would force a strong degree of transparency on every actor and couple that with multiple security teams making sure the system is secured against a growing number of hacks. While the participating exchanges would sacrifice their business data secrecy to their direct competitors, security through obscurity is never a good approach.

Perfection or bust - the rise and fall of The DAO

Perfection or bust - the rise and fall of The DAO

Attacks Bitcoin bugs DAO Ethereum hack Ripple

Full disclosure - I own some ether and I have put some of it into The DAO presale. I don't think it coloured my view of the situation, but I feel it's better to be open about such things.

The DAO has made a lot of waves recently. First - last month when it became the largest crowdfunding project in history, at one point surpassing Star Citizen's 116M USD (although it might be partially due to ETH exchange rate fluctuations). Second time - earlier this week when the DAO was hacked. So lets start from the beginning and have a look at the rise and fall of The DAO.

DAOs, in general

DAO, or Decentralised Autonomous Organisations have been a fairly nebulous concept in the crypto space for awhile. They basically are computer programs that run as an organisation, using its code as law. They can hold digital assets and money that can be spend on various projects, services and other digital assets.

Some have proposed to use DAOs to create a rudimentary self-sustaining decentralised organisations. Such programs would actually use their resources to hire people to improve them. I've heard this concept described first during the 2013's Money2020 Ripple conference, and I would consider BitShares to be one of the first self-sustaining DAOs.

Of course, with the current level of cryptocurrency technology, the DAOs are very limited in scope. They can't be as sophisticated as modern AI running on supercomputers, and since code isn't lawfully binding - the various DAOs have to rely on humans to interface with the outside world.

In theory, DAOs could create a lot new jobs. As @aantonop put it though:

TheDAO will create many jobs. First for people like me who have to explain what the hell it is.

The DAO

The DAO (holding a very generic "temporary name", which it probably won't escape from), created by Christoph Jentzsch, the founder of Slock.it, was set out to be one of such self-sustaining DAOs. It was set up to be a quasi-venture-capitalist-fund. As with many token crowdsales, it was skirting the borders of the law - allowing anyone to invest, not doing any KYC, promising "benefits to the DAO Token Holders", without outright selling securities.

The project had support from a number of high-profile members of the Ethereum Foundation

The DAO started operations by selling its tokens for ETH. The promise was that later the ETH would be used to fund various projects and try to extract value from those projects to the DAO itself. The DAO also had a mechanism to upgrade itself to newer versions of the code. The entire process of both spending money and code upgrade would be governed by the token holders voting. Every vote would be proportional to the amount of tokens held.

By the end of the crowdsale, The DAO has raised 8.26M ETH, more than 10% of the total coin supply.

In theory, The DAO could've been a very strong player in the crypto space. Even if it would spend 10% of its funds just funding early stages companies, it could give out 100k USD to 100 different companies and probably have great ROI by the end.

However, there was a bug in the code...

The exploit

Around 2016-06-17, news broke that The DAO's balance was being drained. Quickly there was a call to all exchanges to stop trading the tokens and Ethers while the situation is being resolved.

As it turns out, The DAO had a small bug in it (discussion, technical overview). They managed to make a recursive call to a function and use that exploit to start draining The DAO of its ETH. Before the attack stopped, 3.6M ETH was extracted, worth about 50M USD give or take 20M due to wild price fluctuations.

The attack stopped around the time Vitalik released a blog post about how Ethereum will be handling the exploit. In the end it was decided that Ethereum will not roll back, instead creating a soft fork preventing the drained ETHs from being spent. The coins would also apparently be reimbursed and everyone that put their money into The DAO would be getting it back.

The following day, we actually got a statement from "The Attacker" about the issue, claiming that the draining of ETH was legal and in accordance to The DAO's rules ("code is law", therefore any execution of the code is always as intended). The Attacker also threatens legal action against any attempt to freeze the drained ETH. If such a case ever made it into a court, it would probably be the most important precedent for the future of decentralised organisations as a whole. Only time will tell where the story goes.

Other criticism

If The DAO has not been taken down by this exploit, it is entirely possible we might've seen a lot of other problems crop up in the future. Here are just some of the possible issues and other ideas that would need to be considered.

Setting a precedent for Ethereum. The way Ethereum handles this exploit may affect how similar future problems would have to be addressed. If they go through with the blacklisting, they might be required by law or asked by the community to do the same in the future for a lot of other things. This can open up a big can of worms. However, if they don't, then they might scare off any other similar projects from using the platform, along with some of their users. Damned if you do, damned if you don't.

Voter apathy. If The DAO would have a large amount of users sitting idly on their tokens rather than voting with their money, the software might have problems reaching the needed quorum to do anything. Apparently in Bitshares, only about 10% of stakeholders participate in voting. Perhaps switching to a Delegated Voting model might help alleviate the issue.

Unexplored legal area. The DAO seems to have aimed to exist in an unexplored legal area. It operates like a security or a venture fund without doing the due diligence. It technically cannot be sued, but people that put money into it might face legal repercussions. All in all, it probably would give any lawyer and government official a headache to try framing it in the existing rule of law.

Lack of KYC. While a lot of people in the crypto community want the government and regulations as far from their projects as possible, some oversight might deter attackers. If every investor in The DAO would be vetted by KYC first, and if only vetted individuals could hold the tokens, anyone attacking The DAO would have to be prepared to get sued and criminally charged for their actions. Right now the best we've got is to try tracing the ETHs they owned back to an exchange and possibly investigate some Ethreum / DAO short calls someone might have set up before the attack (similarly to the idea of "terrorist insider trading").

Rushed deployment. After The DAO has been released, there have been some concerns from people that the code should've been tested and vetted more to iron out any bugs. A code that holds so much money is a gold-filled pinata for any and every hacker that might try to break it 24/7. Some attack vectors have been published before the attack (description and mitigation). Since the contract is vulnerable right after it's released, rushing a release is not wise.

Any bug needs to be fixed immediately. With a smart contract running on a decentralised network, it is vulnerable to exploits all the time. Any new bug that is found needs to be fixed right away, especially if it is described publicly. With more centralised software, you can at least shut everything down until the bug is fixed, but such luxury would be harder to implement in a DAO.

One mistake and your money is gone. While this one applies to most cryptocurrencies, it also bears mentioning - any bug in the code that breaks the smart contract that holds actual money (in this case, ETH) can cost you everything. If you deploy such a piece of code and send money to it, it is gone and you won't be able to get it back.

There are no rollbacks with real coins. While any contract that issues and deals only in its own tokens can be rolled back to any point in time with a patched contract, the matter is not as simple when we're dealing with actual coins (in this case, ETH). As the native coins exist outside of the contract's controls, using such contracts to manage the coins is more dangerous than just dealing in tokens.

Putting all eggs in one basket. A contract holding over 100M USD is a disaster waiting to happen. At the very least some of that money should've been put in some deep cold storage until it is needed. Enter into some legally binding contract with 50 people if you need to to provide some multisig and keep the funds safe. It's like putting all of your coins into a hot wallet - you shouldn't do that.

Paradox of presales. Even if The DAO would function correctly, it might be a hard value proposition, similar to most other ITOs (Initial Token Offering). Unless you are an actual security / fund and building projects that funnel their earnings into the organisation, the projects that benefit The DAO holders rather than Ethereum as a whole might be inferior to the general use case. There is a lot that the Ethereum platform and anything on it could benefit from, but tying them into one smart contract might defeat the purpose. Since many DAOs want to avoid being labelled as a security, we might just get some weird projects in the end.

Relation to other projects

A few people have started comparing this bug to a few other things in the cryptocurrency space. Perhaps it is important to have a look at them and figure out how similar they are.

In the early days of Bitcoin, in mid-2010, someone found a way to create 184'467'440'737.09551616 BTC (almost 10k times more coins than would ever exist) out of thin air in a so called "Value overflow incident". The bug was fixed and the network was rolled back. The bug is similar - use an unexpected way the code works to get access to more tokens than one should be able to. However, this situation is different as it breaks the core functionality of the entire network, rather than a sub-part of it that is not governed by the protocol. Rolling back the network to before the bug was introduced is entirely justified - it is something that shouldn't have happened. With The DAO, the situation is a bit different - the core network functioned as intended, it is the final product that was at fault.

Another incident similar to this was the fall of MtGox allegedly caused by Transaction Malleability, and the attack on JustCoin with Ripple's Partial Payment Flag. In both cases, the software creators did not anticipate an obscure network behaviour that lead to their downfall. In neither cases did the network got rolled back - it functioned as intended, and to my knowledge neither of those companies got bailed out for the bugs in their code. This would probably be the closest analogy.

The decision to bail the contract out and refund the drained ETH might be either seen as the Ethereum Foundation trying to mitigate the damage to the network's reputation, or it might be due to many of the Foundation members lending their credibility to the project itself. One way or the other, I doubt we would see many similar DAOs in the future with such lineup of big name supporters to mitigate any similar damage in the future.

What is also worth noting is that because of Bitcoin's success, a lot of the cryptocurrency projects may "suffer" from an accelerated growth. There have been many incidents in the earlier days of Bitcoin of people losing their money and it wasn't that big of a deal - the coins were worth only so much. However, with networks such as Ethereum being worth a billion dollars less than a year after release, you have similar high profile bugs, but the coins themselves are worth a lot more a lot quicker. Perhaps we should try stalling the gold rush until a project has been vetted by early adopters hammering out all of the kinks and best practices? It's probably not going to happen unfortunately...

Lastly, if the Tau developers want to brag about how their platform is / will be much better than Ethereum since such bugs can't happen there, it is your time to prove yourself - deliver us your implementation of The DAO in a language of your choice so we can pick it apart and see if it breaks.

Conclusions

The DAO has been an interesting ride. It allowed the ETH to double in value and crash back down. A project of this scope if executed correctly would certainly be a game changer for any cryptocurrency network. Unfortunately, as many have made this joke before, it seems The DAO was DOA (dead on arrival). With DAOs, it's perfection or bust.

Spells of Genesis card for The DAO, reading

"Holding so much energy, the Colossus is able to withstand all threats"...

How Bitcoiners see the situation

Transaction data vs metadata - interpreting what has happened

Transaction data vs metadata - interpreting what has happened

Crypto 2.0 data Ripple transactions

With Bitcoin as well as most "Crypto 1.0" currencies, the transactions are simple and elegant. You specify which coins you're spending, what are the redemption requirements, and that's about it. A transaction either goes through, is included in a block and can be spent, or it never gets included and can be safely ignored. However, when we look at the more complex Crypto 2.0 systems, things start to get more complicated - there are many more states a transaction can be in, and we require additional metadata to figure out what really happened.

Transaction data vs metadata

The way Ripple handles its transactions is a good example of the data vs metadata. When submitting a transaction, we submit its data - our intent of what we want the transaction to do. For example:


{
"TransactionType" : "Payment",
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"Amount" : {
  "currency" : "USD",
  "value" : "1",
  "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
},
"Fee": "10",
"Flags": 2147483648,
"Sequence": 2,
}

Indicates that we want to send 1USD from rf1... to ra5... and we pay the fee of 10. Now, when we submit the actual transaction, we also see its metadata:

{

  "id": 6,

  "status": "success",

  "type": "response",

  "result": {

    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",

    "Amount": {

      "currency": "USD",

      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",

      "value": "1"

    },

    "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",

    "Fee": "10",

    "Flags": 2147483648,

    "Sequence": 2,

    "SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",

    "TransactionType": "Payment",

    "TxnSignature": "3045022100D64A32A506B86E880480CCB846EFA3F9665C9B11FDCA35D7124F53C486CC1D0402206EC8663308D91C928D1FDA498C3A2F8DD105211B9D90F4ECFD75172BAE733340",

    "date": 455224610,

    "hash": "33EA42FC7A06F062A7B843AF4DC7C0AB00D6644DFDF4C5D354A87C035813D321",

    "inLedger": 7013674,

    "ledger_index": 7013674,

    "meta": {

      "AffectedNodes": [

        {

          "ModifiedNode": {

            "FinalFields": {

              "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",

              "Balance": "99999980",

              "Flags": 0,

              "OwnerCount": 0,

              "Sequence": 3

            },

            "LedgerEntryType": "AccountRoot",

            "LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",

            "PreviousFields": {

              "Balance": "99999990",

              "Sequence": 2

            },

            "PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",

            "PreviousTxnLgrSeq": 6979192

          }

        },

        {

          "ModifiedNode": {

            "FinalFields": {

              "Balance": {

                "currency": "USD",

                "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",

                "value": "2"

              },

              "Flags": 65536,

              "HighLimit": {

                "currency": "USD",

                "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",

                "value": "0"

              },

              "HighNode": "0000000000000000",

              "LowLimit": {

                "currency": "USD",

                "issuer": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",

                "value": "100"

              },

              "LowNode": "0000000000000000"

            },

            "LedgerEntryType": "RippleState",

            "LedgerIndex": "96D2F43BA7AE7193EC59E5E7DDB26A9D786AB1F7C580E030E7D2FF5233DA01E9",

            "PreviousFields": {

              "Balance": {

                "currency": "USD",

                "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",

                "value": "1"

              }

            },

            "PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",

            "PreviousTxnLgrSeq": 6979192

          }

        }

      ],

      "TransactionIndex": 0,

      "TransactionResult": "tesSUCCESS"

    },

    "validated": true

  }

}

Which specifies, among other things, AffectedNodes - the actual state change exacted on the system. It specifies the balance change of multiple addresses the transaction rippled through. This can be especially important when there are multiple paths a transaction could take, possibly even spanning many different currencies and entities.

How Ripple Works - Gateways and Pathways

All in all:

• Transaction data specifies what we want the system to do
• Transaction metadata specifies what did happen in the system

Lets look at a few examples of why this distinction is important.

Blockchain interpretation in Bitcoin 2.0

Some people use the term "Bitcoin 2.0" and "Crypto 2.0" interchangeably. I personally make the distinction of using the first term only when referring to systems built on top of Bitcoin itself - Mastercoin/Omni, Counterparty, Colored Coins, etc., while using the second term for all cryptocurrency systems allowing one to issue custom currencies (which includes Bitcoin 2.0s as well as systems like Ripple, Ethereum, etc.).

The distinction is important here because Bitcoin 2.0 systems inherently have no control over which of their transactions are included in the Bitcoin blockchain they are using. Unlike Bitcoin, two conflicting transactions can be included in the block and the system has to be able to interpret them correctly. Without transaction metadata, it is hard to tell at a glance whether a transaction is valid and spendable, or whether it is a double-spend and should be ignored.

A cautionary tale of the partial payment flag

In 2014 JustCoin, a Ripple gateway, got into a lot of trouble due to a small feature in Ripple very few people noticed before then - the partial payment flag. When a transaction is created with that flag, it signals to the network "I want to pay the person as much as I can up to the limit specified", rather than "I want to pay the person exactly this much". So for example if my transaction data specifies the amount I'm paying to be 1'000'000USD, but my balance is only 10USD, without the partial payment flag the transaction would fail, and with the flag it would succeed but only give a person 10USD.

The big problem JustCoin ran into was that the transaction data still would quote the big number, even if very little was sent, and only by examining the metadata would they be able to see how much money was actually sent. This meant their attackers could rack up bogus deposits and cash out of the gateway, leaving it short on funds.

Transaction successful, payment failed

While working on a Ripple gateway in the past, I got to explore a few different end states a transaction can end up in - a transaction can be not included in a block and be in an undefined state, it can be included in a block and be successfully applied, included in a block and partially applied (partial payment, open exchange), or it can be included in a block but still fail. In the context of Bitcoin, the last state would be unthinkable.

A scenario where a transaction is not applied to a block is similar to Bitcoin's unconfirmed transaction - it is in a state of limbo. However, with Bitcoin one can still spend other outputs without worrying about the transactions interfering with one another - each transaction output can be spent independently. For systems relying on address balances rather than transaction outputs, a dangling transaction can be a blocker. This is why professional transactions are sent with an expiration date (after which the transaction will definitely fail and not do anything), as well as sending a NOP transaction to overwrite the expired transactions to allow everything else to go through.

Successful transactions that applied fully are pretty straightforward - everything went through (or as much as could in case of partial payment flags).

Open-ended transactions are initialized by one transaction, but end up being fulfilled by other transactions. This applies mostly to the decentralized exchange offers - it's similar to placing a bid on a market and waiting for one or more asks to fulfill it. The transaction only closes when it is fully fulfilled, or it becomes invalid due to low balance, etc.

Failed transactions being included in a block mostly apply to Bitcoin 2.0s and balance-based cryptocurrencies. Those transactions either are inevitable - any valid Bitcoin transaction can be included in a Bitcoin block, but it can be an invalid Omni transaction -, or they are there for simplicity's sake - to do nothing, consume a sequence number and allow next transactions to be committed.

Conclusions

Transaction data specifies what we want the system to do, while transaction metadata specifies what did happen in the system. While not as important to Bitcoin and other first generation cryptos, the transaction metadata becomes more and more important for more complex Crypto 2.0 systems.

Big blocks, small blocks, side-blocks, off-blocks...

Big blocks, small blocks, side-blocks, off-blocks...

21 Crypto 2.0 Gateways Liquid Payment Channels Ripple SegWit Sidechains Spam Wallets

In the recent week Bitcoin has experienced another "stress test" in form of a lot of transaction spam (see below for a chart of the amount of transactions in mempool), although this time the spam was not scheduled and it's not clear who was responsible for it. Along with the continuous debate on whether or not to increase the Bitcoin block size, a lot of people have started looking at what are the potential outcomes of the situation. I have covered a similar topic over a year ago, but it might be a good opportunity to revisit the topic and bring everyone up to speed.

A mockup of "Bitcoin surge pricing", inspired by Uber.

The problem

As some of you know, the Bitcoin blockchain was initially designed to have a limit of 1MB per block. This was done due to prevent the bloat and abuse of the network. However, if this limit is strictly enforced, the Bitcoin network would only be able to support a small number of transactions, about 7 transactions per second (compared to Visa's 2000 tps). Clearly, this won't be enough for a payment network that is supposed to replace the banks and credit cards. Either we will increase this size in some way, or we will see Bitcoin become a much different network.

The outcomes

Depending on whether the block size is increased or not and by how much would dictate how the Bitcoin network is shaped. Lets look over some possibilities.

Block size remains rigid

In this approach, the 1MB block size is rigid and remains unchanged. When we start hitting this limit, the miners will be able to pick and choose which transactions to include in the block. Rational miners will pick the transactions that pay them the most in fees (proportionally to their size), thus there will be a bidding war to get into the next block.

Due to the increased cost, fewer people will opt to send transactions themselves, either leaving Bitcoin entirely, or by performing some off-chain settlement. Wallet services such as Coinbase could become more like banks - offering their customers settlement with other people on their platform and other platforms that accept off-chain settlement.

In this scenario, Bitcoin becomes a settlement method for large bank-like wallets and large corporations.

Block size limit is abolished

A polar opposite of the previous approach. The block size limit is completely abolished and miners can create arbitrarily big blocks. While anyone can create a transaction for cheap, the network would soon be attacked by malicious entities trying to push the limit. Someone could decide to generate a 1GB block for example and cause the network to grind to a halt while synchronizing.

Quite quickly running a full node becomes a luxury or a business. We see more reliance on Stratum-like supernodes. The functionality of the network is dictated by them.

In this scenario, the Bitcoin network turns into something like the modern Internet - only big players can access it directly and everyone else has to rely on something like Bitcoin-Internet Service Providers.

Middle of the road

The most likely scenario would be somewhere in the middle of the road - raising the block limit, but doing so gradually. Dedicated users could run their own nodes, but most of us would rely on third parties for helping our wallets function.

Alternative solutions

Bitcoin is both an independent currency and a settlement network for that currency. Whether the block size increases or not, there are a lot of ways one could try enhancing the settlement aspect of Bitcoin.

Soft forks

There are some proposals on how to improve the scalability without hard forking the network. Some of them include softforks such as Segregated Witness , or Sidechains (allowing value to be moved in and out of the Bitcoin network without a trusted third party).

Segregated Witness, or "SegWit" is a solution focused on slimming down the transactions by moving the signatures off-blockchain. This can slim them down to about a quarter of the size, essentially allowing the Bitcoin network to process 4MB of transactions in 1MB blocks. The idea appears to have a lot of support, but since it's mostly streamlining what Bitcoin can currently do rather than creating a whole new solution, there isn't much left to explain without going into technical details.All in all, SegWit can buy Bitcoin some breathing room with its current block limit.

Sidechains is an idea focused on on being able to move the value in and out of the Bitcoin network without depositing the coins with a third party. While this doesn't sound like much, sidechains can lead to a lot more than just scaling Bitcoin - they have a potential of recreating networks with the features of Ethereum or Ripple without having to bootstrap those networks with new coins. These sidechains could be used to settle BTC transactions outside of the network while still not having to worry about the counterparty risk.

Payment channels

Payment channels in general or Lightning Network specifically are an interesting approach to allowing a large amount of transactions to take place outside of the Bitcoin network while everything would still be settled on-chain. The idea was discussed as early as 2011, and today we have some companies that even start advertising it on their websites:

21.co advertising their payment channels right above telling everyone how many blocks it might take to confirm various transactions during the recent spam attack

A payment channel is a way for two nodes to pass payments back and forth between one another using unbroadcasted Bitcoin transactions. Each payment adjust the balances between the nodes - shifting the balance back and forth accordingly. Only the final transaction gets published to the whole world, thus potentially saving a lot of space in a block. While the use case for this solution might be limited (who sends another person multiple transactions over a short period of time?), it gets more interesting when you add the network effect to it.

A simulation of 6 networked payment channel nodes

Now, when you introduce a few "supernodes", possibly in form of Bitcoin exchanges and big companies, you start mimicking the Gateway model of Ripple:

An illustration of the Gateway model of Ripple

Instead of settling directly on the network, anyone can potentially save a bit of fees by connecting to one of the supernodes and establishing a payment channel with them. This would allow you to transact with anyone in the network fast and cheap, while still being able to settle your balance on the Bitcoin blockchain as needed. If the payment channels are open for a long period of time, a lot of people could begin to operate solely within the network. This might be especially important for cross-exchange settlement, or for shared ewallets like Coinbase or 21.co.

Alternative networks

Last but by no means least, we have the alternative networks. A lot of them stand to benefit when the Bitcoin network falters.

Simplest ones would be the altcoins - Litecoin and the like. They reason that if Bitcoin blocks are full, people will join other networks and use other coins instead. I'd take that with a grain of salt, after all, Bitcoin is a better currency in terms of price and market cap than its alternatives, but the other networks might have a higher throughput.

How /r/dogecoin sees the situation

A much more compelling alternative would the the Crypto 2.0 networks and permissioned blockchains - Ripple, Open Transactions, Liquid. Those networks can use the above mentioned Gateway model and move the settlement completely off the Bitcoin network. The only transactions that would need to be included in the blockchain would be deposits and withdrawals. While certainly more rigid and centralized than the payment channels, there are ways of preventing the gateways from stealing one's coins (such as Voting Pools). Moreover, such networks could also be used to issue fiat-denominated IOUs, which might be very attractive for some applications.

Conclusions

The Bitcoin block size debate is still going on, while the blockchain limit is being hit more and more often. Either the Bitcoin network will scale to larger blocks, or higher fees. There are many solutions out there focused on providing alternative means of settling with BTC without having to further burden the Bitcoin network. Only time will tell how our current problems will be addressed and which solutions will be used.

Sample bankchain feature set

Sample bankchain feature set

Bankchains Banks BitShares Blockchain Crypto 2.0 Liquid Permissioned Blockchain Ripple Sidechains smart contracts Smart Oracles Voting Pools

In the recent months, many banks and other financial institutions started looking into the blockchain technology as a potential improvement on their current architecture. Below is a sample feature set of the cryptocurrency technologies that can be used to reimplement and possibly improve upon the banking system as it is today.

Transactions

In all cryptocurrency systems, transactions are the most basic building block of the value transfer network. They have a few important features, including:

• Atomic nature - a transaction can either succeed fully, or fail completely. There is no middle-ground that wasn’t specified beforehand (for example, Ripple’s partial payment flag). It is even possible to have complex transactions that hop across multiple currencies that are still atomic. 
• Self-contained - a transaction in most cases provides all the information that is needed to verify whether it is valid or not. It specifies exactly which money it is spending, quite often how much money is left, as well as contains a digital signature authorizing the move of funds. 
• Undisputable ordering - once transactions are included in a block, their ordering is undisputable. This allows everyone to be able to verify exactly what state the system was before and after the transaction was applied. There is no data discrepancy between the participating institutions as to what happened without the need to resort to a centralized authority. 
• Cryptographic authorization - in the crypto world, there is never a doubt whether someone is authorized to spend the money. Either they own the private keys and can authorize the payments, or they don’t. Moreover, each signature is only valid for a given transaction, so a few authorization problems are mitigated (replay attack, man-in-the-middle, etc.). 
• Easy multi-party escrow - also known as multisig. This allows money to be held by multiple parties in such a way so as to only be spendable when a minimum threshold of parties agrees to spend them. 

Currencies

In the cryptocurrency space, there are essentially three types of currencies.

The most prevalent is a native crypto currency or a digital token. Those are currencies issued by decentralized autonomous organizations, either in the form of complete crypto-networks (like Bitcoin, Litecoin, etc.), or autonomous smart contracts. Those tokens are usually perfectly, mathematically scarce, have a predictable minting schedule and a clear set of rules on how to transact in them. However, due to their decentralized nature, they don’t represent real-world assets very well.

The second kind are derivative currencies (such as BitUSD), which are still created and maintained in a decentralized fashion (without a central or collective counterparty), but through known financial contracts (futures, contracts for difference) can track the value of real-world assets and currencies. Their counterparty risk takes the form of the financial derivative market.

The third kind are IOUs, digital currencies issued by centralized or collective parties usually backed by real-world assets and currencies (such as SnapSwap.USD, BitStamp.BTC, etc). While they are subject to counterparty risk, they have an advantage over the derivative currencies by most often being easily redeemable in kind from the issuer.

Different cryptographic systems have different requirements when it comes to those currencies. A decentralized network will have to have at least the native digital token to avoid spam attacks at the very least. Having that currency, they can also incorporate the remaining two as needed (see BitShares and Ripple for an example). Permissioned blockchains don’t need a native digital token, as the network participants are known entities and can be made liable in case they intentionally disrupt the network. As such, it makes a lot more sense for those networks to mainly feature digital IOUs.

IOU issuers

IOUs in a cryptocurrency network can be a powerful tool. They are useful for not only tracking the value of real-world assets, but also for tracking the trust associated with the currency issuer. If 1 USD from Bank A trades for 1.02 USD from Bank B, we can infer that A is more trusted than B.

When talking about IOUs, there are generally two models that can arise in a system - a web-of-trust or a gateway model (with the real-world examples usually being a mix of the two). In the first model all parties trust one or more parties in the web and money flow is rippling through the system between parties (this is a basis for old version of Ripple). In the gateway model, we have a few central authorities everyone relies on to securely issue and redeem the IOUs everyone else uses (this is a basis for the new version of Ripple). The latter approach might be more useful when there are different classes of peers on the network (governments vs big banks vs small banks vs credit unions, etc.), but the former is useful compliment for smaller-value settlement between the same classes of peers.

IOUs inherently track debt between parties (if you have 1USD IOU from me, it means I owe you 1 USD). In systems like Ripple it is also paired with another variable - trust. Trust limits the amount of IOUs / debt one is willing to take from another individual. This can be especially useful if say, two banks established a mutual trust between one another to simplify payments or reduce their costs. They might agree for example to extend $1M line of credit between one another and use that channel for settlement for any payments made between their accounts. If the credit limit is ever reached, they can still settle with potentially more expensive IOUs from a gateway (say, a government), or settle the debt in some other way and resume operating with the cheaper IOUs.

Decentralized exchange

Having a number of currencies issued on a decentralized network opens up a lot of possibilities. Most useful one perhaps being a decentralized exchange allowing trading between any currency pair. With an open market accessible to all peers, one could expect to drive the spread for performing FX trades to spot, even for small value transactions. Having that, one could expect to start seeing the Singularity of Money going into effect, where the currency you own would not matter as much as the value of that currency. Multi-currency hops would allow one to route money through the most efficient market in the web of value allowing for easy bootstrapping of new remittance platforms and applications.

KYC

An important aspect to consider while designing a crypto network is how it can comply with KYC regulations. While decentralized networks such as Bitcoin are focused on fostering strong pseudonimity, permissioned blockchain users in most cases would be interested in dealing only with known parties. This can be achieved by either having all entities in the system known and explicitly recognized, or having a more open system but with each peer being responsible for doing their own KYC.

The first is a model that seems the most popular with private permissioned blockchains such as MultiChain, where the creators of the system explicitly have to grant read and write permissions to every network participant (thus giving them an opportunity and potentially a responsibility to perform the KYC on everyone).

The latter model is more popular on public blockchains that allow permissioned access, such as Ripple. There, every gateway can explicitly either blacklist addresses to prevent them from using the IOUs they created, or create a whitelist of only the addresses that can send and receive the IOUs.

Block encapsulation

One of the more important differences between a database-based approach and a blockchain-based approach for processing transaction is the idea of encapsulating transactions in blocks. A blockchain, whether it is permissioned or public, has a few key advantages:

• Order of transactions is strict - there is no doubt which transaction is to be applied first and at what time. This addresses the problem of race conditions and can be used to address the problem of frontrunning in a system without a central authority. 
• History is immutable - since all blocks in a blockchain refer to a previous block’s hash, it is impossible to alter any record of what blocks and transactions took place in the past without rewriting it entirely. Paired with real-time anchoring of block hashes into a public immutable ledger such as Bitcoin ensures that any block forks would be evident and would have to be accounted for. 
• Provable auditability - knowing only the latest block hash (which is a small digest in comparison to the actual size of the blockchain), one can not only audit the entire history of the blockchain, but the auditee can probably for the first time in history provide a positive proof that they disclosed all the data for the audit. Any records that are missing or have been altered will come up in a proper audit. 
• Everyone can be sure they have all the data - if one is at the blockchain head, they know they have or can fetch all historical data. There is no doubt whether some chunk of data is missing or not. 

That being said, blockchains are not a silver bullet. They come with their own weaknesses:

• Blocks are slower than individual transactions - while a transaction can be committed to a database within a few read/write cycles, a block takes awhile to be created and propagated. The fastest blockchains out there achieve about a block per 1-5 seconds. While each block can contain many transactions to possibly reach the required throughput, those transactions can only come in discrete quantas, not a constant stream (as they say, “Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.”). 
• Performance-wise, a blockchain will probably have a higher transaction overhead than an optimized database. There are a few possible reasons for this - the fact that in the end transactions from a block will have to be committed to a database anyway, the overhead of synchronizing the network and resolving forks, or the relative age of Bitcoin technology (7 years) vs say, SQL (about 40 years). 
• Currently, there are many blockchain-based cryptocurrency solutions out there, but there are also cryptocurrency networks out there that don’t rely on blockchains, such as Open Transactions. The latter relies on having a few notaries verifying transactions in real time and providing cryptographic receipts for those transactions. It is an interesting approach that allows anyone to prove their balance by merely presenting the last receipt without having to hold onto any prior history.

Tiered blockchains and bandwidth reduction

As it became evident in the Bitcoin world, blockchains can become vulnerable with increased network activity. As such, a modern blockchain solution for high-transaction-volume environment should be prepared to address the bandwidth issue before it might become a problem.

There are a few possible approaches one can take - settle transactions off-blockchain (like the Lightning Network), create a separate permissioned blockchain (like Liquid), or create sidechains (like Credits or what Blocksteam initially wanted to create). Out of those three, sidechains appear to be the more ideal solution - allowing one to move value on and off the main blockchain, transact on that blockchain with the transactions being cryptographically linkable to the main chain (through anchors), and not rely on more centralized third parties.

As such, it might be feasible to construct a tiered blockchain that would be able to offload a good amount of transaction volume off the main chain while still allowing settlement between tiers. At the top of the chain we would perhaps have a public blockchain where the highest-tier peers would issue their IOUs - governments, biggest banks, etc. Below that, we would have sidechains maintained by various banks and other financial institutions. This would allow them to perform more internal transaction without cluttering up the main chain. If needed, more sub-sidechains could also be introduced to further increase transaction throughput. One could also perform sidechain-to-sidechain transactions through a dedicated protocol (such as what Interledger is proposing).

It would be useful for the top of the chain to be a public blockchain as it would allow more institutions and possibly even governments to join and integrate directly with it.

Sample network graph of a tiered blockchain:

Proof of Solvency

One very interesting concept that emerged from the Bitcoin world is so called “proof of solvency”. It allows institutions such as exchanges or gateways create a positive proof that they own a certain amount of currency and that their liabilities are no greater than their currency reserves. Depending on the system in question, the proofs can be either be complete (proving beyond a shadow of a doubt both the assets and the liabilities) or disprovable (one can present undeniable evidence that the institution is lying).

The first scenario is mainly applicable for completely open ledgers - in most cases, only cryptocurrencies and Crypto 2.0s. For example, BTC2Ripple can prove both that they own a certain amount of bitcoins AND the level of their outstanding liabilities on the Ripple network. Since both networks are open, the transaction can be verified to be true or false at any given time.

The second scenario applies whenever we’re dealing with either closed networks, or networks that don’t provide cryptographically signed proofs. This includes exchange’s private databases and bank statements (barring something like TLSNotary). In this case, we either have to rely on some signed documents or PDFs supplied by the banks about the account balances, or generate a merkle tree of all account balances on an exchange. An exchange cannot prove that the information is complete, but anyone can prove the data is invalid if they find their account balance either omitted or altered.

As such, Proof of Solvency can be an important tool for financial audits, allowing them to be performed at any time without disrupting the normal business operations. Some institutions might even opt for continuous proof - updating the required information in real time to bolster confidence in their business.

Proof of Solvency might be fairly straightforward in the above proposed tiered blockchain. Any balance in a sidechain should equal to the amount of assets held at the higher-level chain. The top-level chain would have clear balances of who has how many assets and liabilities.

Voting Pools and auditing competitors

Voting Pools are an interesting idea for keeping everyone honest. In this approach, we have multiple parties vouching for one another’s solvability and being liable for bailouts in case one of the parties goes under. For example, we could have multiple exchanges forming a voting pool and keeping their bitcoins in multisig addresses such that even if one of them turned rogue, they couldn’t defraud their customers nor turn insolvent. This is made possible with continuous proof of solvency, as explained above.

Voting Pools could also be useful for having multiple institutions creating IOUs backed by all of them. These could include:

• The Euro currency, issued by the joint agreement between multiple EU countries 
• International Special Drawing Rights issued by the International Monetary Fund 
• Fiat IOUs backed by multiple banks 

While Voting Pools are the most efficient in a network based on native cryptocurrencies such as Bitcoin, the concept might also be used in permissioned blockchains.

Smart contracts

The final catch-all solution for everything one couldn’t predict while designing the system. Smart contracts are flexible programs that live on the blockchain and can execute commands based on the state of the network. Coupled with smart oracles, the contracts allow for creation of such projects like a decentralized prediction market.

Conclusions

There are many practical applications of the blockchain technology for banks and other financial institutions. Failing to embrace the new technology might make the old network obsolete. The above are only some of the examples of what can be achieved and it is very likely we will see a lot more innovation in the following years. Even from those building blocks we can construct innovative technologies (such as self-regulating universal basic income).