Crypto 2.0 Musings – Multi Asset Chains

The more I learn about Crypto 2.0, the more excited I get about it, but on the other hand the more I realise just how nascent it is, and the need for compromise  between today’s rails and Crypto 2.0 rails, and compromise between different emerging architectures.

I am starting to notice patterns of attributes and their dimensions that differentiate the various platforms, and the choice of compromises along a multitude of these attribute dimensions may have profound implications on the future architecture of finance.

permission-ed versus permission-less ledgers

I have already talked about one of the attributes in the Mining Rights blog – permission-ed versus permission-less ledgers. It looks like right now permission-ed ledgers offer an easier route to clearly identify both the miners and transaction issuers, so legally speaking a better fit for existing financial services, and have better latency as proof of work in not required – hence likely to be adopted first.

plaintext pseudo-anonmous transactions versus cyphertext transactions

Once homomorphic encryption is added to blockchains, a new dimension will emerge – plaintext pseudo-anonmous transactions versus cyphertext transactions, where the source, destination and contents of transaction are all encrypted, still verified by all, but readable only by private key holders. Protocols like ZeroCash are already making inroads today, see the Transaction Privacy blog.

identity and credentials

Yet another dimension is identity and credentials. Bitcoin for instance is pseudo-anonomous i.e. it has no in-protocol feature to relate a public wallet address identity to a legal entity, or better still assure without disclosing legal identity that the pseudonym has been attested by a reputable and trusted entity as having required credentials e.g. KYC checks. There are hacks to get closer though – see Simple Attestations blog.

As some dimensions develop, they may make others mute. For instance, permission-ed ledgers may not be required if platforms emerge that support

• quorum-slice consensus thus avoiding proof-of-work energy waste and latency issues but still featuring un-restricted access
• cyphertext transactions thus removing need for closed networks to ensure privacy
• credential attested pseudo-identies thus providing legal recognition

to Bitcoin or not to Bitcoin – that is the question

Then there is the question of whether you back off to Bitcoin or not. Many argue that Bitcoin has gained critical mass and there is no point in using something else – you can use colored coins and middleware solutions like Counterparty and Omni Layer to build on top.

I think there is significant risk with this approach as Bitcoin uses game theory and economic incentives to prevent attack, but if Bitcoin’s market capitalisation becomes much higher than face value, as coins are coloured, it may create new attack vectors that break the balance. Then again, I can see the attraction of building on top of Bitcoin too.

single versus multi asset chains

One dimension I wanted to discuss further in this blog is the number of assets a chain has been designed to support. IMO, Bitcoin is inherently a single-asset blockchain, supporting only the Bitcoin virtual crypto currency. For now let’s ignore colored coins and how they alter that statement, as they were never mentioned in the original white paper.

Although Bitcoin allows for custom scripts that open up possibility for use cases other than crypto currencies, they are not Turing complete i.e. no loops – a design decision to prevent an attack on the network by using an infinite loop transaction.

In fact most logic is fixed at protocol level e.g. currency issuance, consensus etc. A further restriction is that most miners will only accept five types of script, again to protect against rogue script attacks.

Something like Ethereum on the other hand is a multi-asset blockchain by design as it supports the ability to create smart contracts a.k.a. distributed applications with custom logic, thus enabling modelling and creation of, in principle, any kind of financial or other instrument. To support this complexity, such platforms have to support Turing complete scripts.

Support for Turing complete logic can be provided in different ways. Ethereum allows you to upload a custom distributed app and start using it without modifying verification servers. Omni Layer provides a middle-ware tier that allows for business logic plug-ins, that must be installed and upgraded as appropriate on all verification servers. Others fork Bitcoin or other platforms and provide altcoins.

Eris takes this even further and allows you to work against different types of distributed ledgers for its persistence layer, unlike Ethereum that bundles smart contract execution and storage into one. This means that you can execute your code against either a permission-ed or permission-less ledger as appropriate for your use case.

asset-class chains

Then there is the middle ground, let’s call it asset-class chains e.g. NXT, Ripple, Stellar. These chains may support one or more asset classes e.g. multiple types of loyalty coins, or fiat pegged proxy currencies. They may have one or more templates for an asset class, and as long as you are happy with the built in business logic, you can in effect instantiate a variant of them for your own purposes.

From an operational cost point of view, personally I am more drawn to multi-asset chains as the potential need to mine hundreds of different chains and dealing with side chain pegging etc., something that has been talked about but is very nascent, makes me think will have high overheads.

One of the downsides of a single multi-asset chain is risk concentration. Not the traditional operational risk associated with a central operator, there is none, but risk of protocol defects effecting all financial instruments. That said, much of the modern banking and indeed the world already relies on common sets of Internet protocols.

The other downside I can think of is performance. Multi-asset chains have to by default be generic and not optimised for specific use-cases, whilst single-asset and asset-class ones can be optimised. Protocol or plugin code can be run outside of a safe VM where custom code is executed, something not possible with distributed apps, as VM guarantees isolation and protection against rogue code.

Take Ripple and Stellar – they have created a decentralised exchange capability using order books, and implemented it as part of the core protocol. Same order book concept could be implemented in Ethereum as a distributed app. I have not tested performance, but I would assume Ripple and Stellar will be faster.

So it may be that higher frequency use cases will have to use protocol or plugin centric solutions, at least until distributed app platforms get fast enough.

Crypto 2.0 Musings – Simple Attestations

Just finished Hackcoin – was meant to be a judge but got into a very interesting discussion with some brilliant people and ended up becoming a team member.

The challenge was pretty simple – how to create a digital identity solution on blockchain, and make it useable via on-chain smart contracts or off-chain by some means.

Went through a number of pivots, and ended up with the most narrow use case we could think of that could potentially be useful – a car hire company needing to check with DVLA if the renter is allowed to drive a car.

Recently, UK’s DVLA stopped supporting paper part of the driving license – the bit that contained any points and other information about status of your licence. So the only way that a car hire can now check validity of the license is to either use DVLA’s website or phone up a DVLA support number.

Maintaining a website capable of supporting millions of concurrent calls is always expensive, and if you experience teething problems like the ones reported at launch, it can lead to loss of business to car hire companies and frustration to car renters.

So, could blockchain come to the rescue? Of course, why would I be blogging about it 🙂 Diagram below shows the flow.

The car renter rocks up to the car hire place and presents their driving license. Assuming the car rental office has internet access, they use a mobile or desktop app to either key in or OCR the driving license number, plus the set of driving permissions.

The app would then hash the concatenation of these two values and search the blockchain for a transaction with the hash value in it’s body and issued by the DVLA’s public address as advertised on their official website. This preserves driver’s identity as hash functions are one way only i.e. you can’t determine the driving license number based on hash value, just check if it is the same by re-running the hash function on the data.

The found transaction should contain the hash value plus a True or False flag to confirm if the status of license is as advertised on the driving licence. If multiple matches are found, as DVLA updates the status due to points being added or removed etc. then latest should be used. Assuming that a latest transaction is found with a True flag, car hire company is now satisfied and releases the car.

But how does the transaction end up on the blockchain in the first place? Whenever the DVLA issues a new driving licence or processes an event e.g. new points from police, expired points, expiry etc. they hash the concatenation and send it as a transaction.

Note, so far no mention of which blockchain is to be used. The nice thing about this solution is that you don’t need a Turing complete smart contract enabled chain i.e. you can use Bitcoin, NXT or Ethereum etc. A more powerful solution could of course be built with better access controls if a smart contract capable chain is used. As these attestations have little monetary value, they should not upset the proof of work incentives.

Finally, DVLA could either send a message to it’s own address e.g. Bitcoin, or upload it as tagged data e.g. NXT, but it could also send it to the user’s public address. Why would you do that?

Well, let’s say DVLA sends the driving licence along with a secret number to your home address. You could then create a transaction using a hash of your driving licence, your face’s key features extracted from photo and the secret number and send it to the DVLA as a trasnaction, thus proving that you indeed got the licence and associating it with your public wallet address and face.

The DVLA could monitor the blockchain and when it spots such a transaction it could then as described above issue an attestation transaction, but this time it would send that data to the user’s public address. This creates a link between the public address, driving licence and the attestation.

A renter could then in principle turn up to the car hire shop, who take a photo of the person and issue a challenge to the user’s app that can only be solved if it is the bearer of the private key and knows the driving licence number, assuming a successful response and a face key features match verified against the hashed version would verify the bearer as license holder, all without having to even have the driving license.

Appreciate that this is all dependent on on-line services being available, and do not propose that this is the only channel, just another one for now. I also assume there are a million and one flaws in the above proposal.

On the other hand, maybe it can be fixed up to be workable and if it can be made to be better enough than today’s solutions, and cheaper, in which case if other agencies and service providers e.g. utilities, universities, employers etc. join this method, you could see how it can used then for digital identity and KYC for on-chain manual or smart contract checks.

Crypto 2.0 Musings – Mining Rights

A lot of discussion has recently centred on permissioned versus permissionless ledgers.

Permissionless ledgers like Bitcoin offer censorship resistant open access but sacrifice speed of transaction confirmation and green credentials as expenditure of electricity is used as an anti-attack mechanism.

Permissioned ledgers on the hand tend to have much faster transaction confirmation times, can deal with more transactions i.e. better latency and bandwidth, and create natural Circuit Breaker, Digital Identity, KYC and AML checkpoints. On the other hand they require some form of regulation to decide who can join the network, possibly leading to higher entry fees and closed anti-competitve behaviour.

My hunch is that in the future we will figure out a way to have the latency, bandwidth, circuit breaker and identity attributes of permissioned ledgers but retain the open access of permissionless ledgers. In the meantime, I think it is likely that permissioned ledgers are likely to take off in the more conventional, commercial use cases. For that to happen though, we will need to solve the governance issue – who owns and hands out mining rights!

Before exploring solutions, let’s recap why this difference in permission models exists. Bitcoin is worlds most capitalised permissionless ledger – there is no central authority that determines who is able to join the network and who is able to issue currency.

Bitcoins are issued by the protocol itself based on a predetermined algorithm – each miner a.k.a. transaction validator and keeper of a local copy of the distributed ledger, who is first to successfully guess a random number linked to a fingerprint of the previous block and of all transactions in the current block gets to issue to themselves some predetermined number of bitcoins, 25 today, plus the transaction fees. Issued amount will keep halving over time using a decay function till all currency is issued and at that point miner’s only reward will be the transaction fees

This random guessing is what’s called proof of work and is a very clever mechanism to guard against one of the top three attack vectors against a crypto currency like Bitcoin.

When transferring money you naturally want to make sure that only you can spend your money, and only the intended recipient gets the intended amount of money i.e. the transaction is not mutable and is issued by the rightful owner only.

first attack vector

So the first obvious attack vector is to somehow either issue a transaction on behalf of someone else and transfer money to yourself or corrupt an existing transaction to divert money to yourself – private keys and cryptography are the mitigating technologies that assure that only the private key bearer can spend the money linked to that key and digital signatures ensure that the transaction is not corrupted.

Bitcoin, unlike a conventional database, also includes scripts with each transaction that allow people to place custom conditions that must be met for the transactions to be considered valid by miners and stored in the ledger. A simple condition could be that only the owner i.e. private key bearer, can send a transaction spending some of their money, and they also place an encumberement on that transferred money, that only bearer of the private key linked to new public address will be able to spend it.

Each miner then executes this script, also checks for double spending and only if the script’s execution output is a positive return will the network recognise the transaction as valid and signal miners to store the transaction in their local ledger instances.

second attack vector

So it’s paramount that along with the transaction details like the amount of money, as well as source and destination addresses, the script is also not compromised – the second attack vector. This is where again digital signitures step in to sign the transaction validation code and ensure that is is immutable.

third attack vector

There is however a third attack vector and that is, just because the transaction inputs and script can be verified as immutable and issued only by private key bearer, the miner is still free to interpret them any way they wish.

I can write a rogue miner that will allow me to double spend my money and if I were to gain 51 percent of the network, I would be able to add normally invalid double spend transactions on to the main fork of the blockchain and effectivly print my own money. In other words, just because you tell someone what to do, there is no guarantee that they will actually do so.

To dis-insentivise people from creating rouge miners, Bitcoin implements the consensus backed by proof of work mechanism – roughly 51 per cent of the participants must agree that the transaction is valid before it is accepted by all. So even if 49 per cent are dishonest, you still will see expected results. However if all you need to do is check the transaction and send out the execution result as a vote, then even a single laptop could flood the network with false votes.

Somehow you need to ensure that either one entity has only one vote, but who would be that regulator, or you make it expensive to vote. Bitcoin makes it expensive to vote through cost of electricity you have to burn to vote by forcing everyone into a race to be the first to to guess a random number within a predetermined by algorithm range and depended on the block fingerprint, which roughly takes 10 mins to guess, in return for issuing new Bitcoins to yourself and keeping the transaction fees.

If there are say 1M nodes, you would need to have over 1M of your own servers burning electricity to take over network i.e. it is currenlty cheaper to be honest and collect mining fees and new coins than to cheat. This is an elegant solution if you do not desire to have a regulator, but has huge environmental and financial cos, it also impacts transaction confirmation latency as you have to wait approximately 10 mins before first confirmation, or 60 minutes as best practice  suggests.

The already discussed alternative is to have a permissioned ledger – someone issues lets says a mining license and allows some entity to join a private network and mine transactions. This works well within national regulated markets but not so well in international settings – after all who would be the regulator – UN?

Even if an international regulator were to emerge, how would they determine how many licenses say each country were to get? A risk is that a country would request 51 per cent of licenses and take over. Lets assume though that somehow an acceptable to all primarily license issuance scheme were to be devised, a secondary dark-web license market may emerge and a hostile entity could buy up or hijack 51 per cent of the licenses and launch an attack.

So what’s the alternative for an international setting, a common use case for most of Crypto 2.0 internet based projects? Long term, as mentioned already, I hope we find a better solution to proof of work but one that still offers  open access, since research suggests openness promotes innovation and inclusion.

In the mean time, perhaps the first step for markets where the need for low latency, digital identity for legal enforceability and low cost of transaction processing is more important than open access, is to create a permissioned system where licenses are issued at protocol level only with the consensus of the existing members e.g. a bit like an EU process to accept new member states.

If such a solution were to be seen as favourable, then chain protocol authors would have to build in voting for accepting and rejecting new members – not aware of any system that already does this.

Such a process removes the need to create an international regulator, but ensures that that it is self policing as members will have vested interests to keep each other honest. Existing international and national anti-monolopy laws can still be used to ensure such a network does not promote anti-competitve behaviour.

There are alternative models e.g. proof-of-stake and bond systems. Proof-of-stake links voting rights to the amount of asset you hold on the chain, but some argue that it can lead to increased chain forking i.e. lack of consensus. Bond systems on the other hand require participants to put some money up which will be confiscated if a participant causes a fork i.e. a direct financial penalty.

Crypto 2.0 Musings – Legathon Notes

Thank you to all those who participated in world’s first half-day Crypto 2.0 Legathon hosted in UBS’s Level 39 Innovation Lab. Keen legal and technical minds with interest in Crypto 2.0 spent over 4 hours in a “transaction structuring” experiment.

For those like me who are not from a legal background, “transaction structuring” is about working out the legal structure – data flows and corresponding flows of legal rights and obligations. We chose to focus on a specific use-case, an FX swap, and then perform an issue-by-issue walkthrough on what would be needed at each phase of the transaction, in other words a legal “attack vector / penetration test” phase where we cogitate possible failings with the structure.

We ended up defining a use case where two companies choose to do an FX swap over a hypothetical blockchain, but since Ethereum was there, we kind of drifted towards it being the rails. In the use case, one company is based in UK, the other in Canada. The UK company holds asset backed crypto cash pounds issued by a UK bank, which in turn holds an equivalent deposit with Bank of England, and a symmetrical arrangement exists on the Canadian side.

To mitigate counter party risk within the swap transaction, both companies send money to a wallet owned by an FX swap contract, primarily an escrow arrangement, issued by some organisation e.g. law firm, bank etc. The FX swap code takes custody of pre-agreed at contract instantiation crypto cash, transferred to it by both parties, and if all is as agreed, the contract takes its transaction fee and pays out crypto GBPs to the Canadian company and crypto CADs to the UK company.

permissions and ledgers

Early discussion focused on permission-ed versus permission-less ledgers. Whilst permission-ed ledgers do have the advantage of latency, throughput and energy efficiency, it’s still possible that secondary mining licenses markets will emerge and a hostile entity may buy them up and dominate the chain to ill intent. 

Also, in an international setting, who would be the regulator and which countries would accept control over them by some other country, so a permission-less ledger may end up being more acceptable in that scenario. Case for permission-ed ledger within clearly defined national borders or existing regulated markets is more compelling.

distributed apps not smart contracts

We also made an observation that ‘smart contract’ as a term is really unhelpful because legally a contract is a meta construct within a judge’s and counter party’s minds that is an aggregate of presented evidence, code alone is not a legal contract. Perhaps smart contracts should be thought of as distributed apps (Eris uses that term) that could be part of a legal contract.

who owns the smart contract

Ownership is important because in case something goes wrong you will need to understand who is liable. In case of the swap going wrong, do you hold the owner of the contract liable, the miner or whoever activated the contract? What if the contract has been called by another smart contract – you would need to ultimately trace it back to some legal entity, a bit like tracing legal entity hierarchy. What if the smart contract is an AI construct with a non-deterministic outcome, is the owner still responsible? PS probably yes.

According to western law, a machine cannot own a contract, only a legal entity, person or company can do so. It is likely that a court would view a smart contract as a machine, hence from a legal point of view for the smart contract to have legal validity it would have to be owned by someone. Think of a coke machine, it can accept money, but what happens if it does not deliver the drink once payed? It always has a number to call for unintended circumstances.

It is likely that in the future many smart contracts will be commoditised e.g. you would choose an off the shelf FX swap smart contract and create an instance of it. Hence the legal owner could be seen as someone who either wrote that contract, or owns it’s IP or copyright, or someone who deployed it, or most likely whoever collects execution fees.

You should also consider cases where malware takes over and issues un-intended transaction. Blockchains once confirmed are largely non-reversible, so you would need to provide reverse transactions to fix unintended trades. Should you also look for insurance products to mitigate some of those risks – probably yes.

circuit breakers

At a system level, we also need to consider what happens if malware takes over, or unintended spirals of trading occur due to complex and unforeseen interaction of algorithmic trading smart contracts.

To prevent financial system meltdown you could consider building in code into smart contracts or into mining nodes themselves to stop transactions being processed or possibly to be reversed if some authority issues a stop and desist command. But who would be that authority?

stipulating jurisdiction

One of the questions we asked ourselves was which court you would use to settle a dispute within our use case – would it be UK, Canada or wherever the transaction was mined. Turns out the common practice is to stipulate the jurisdiction within the contract that two parties enter into.

So how can you stipulate that when the contract is made up of code? Emerging practice is to write legal prose contract, hash it and bind that into the smart contract’s code – hence now code and legal prose make up the combined legal contract. Interestingly, the legal contract is always between the two parties, the smart contract is just an execution flow trust convenience. 

Interestingly any jurisdiction can be stipulated e.g. country or even a made up one like blockchain court or a kindergarten. Problem comes with enforceability – just because a court rules, will the counter party accept the ruling or simply ignore it, and will the court have enforcement rights. This is where national courts with local enforcement capability will still likely be the fall back option.

Internationally it gets more complicated, you could resort to asset freezing if a party refuses to abide by court ruling, but that assumes it has assets to freeze within relevant jurisdiction. So commercial due diligence on smart contract owners is key, possibly backed by insurance. A number of international conventions exist to help with international trade and law, so perhaps we need a new blockchain convention?

accepting terms

How do you know if both parties accepted the terms of the contract, a legal requirement. You could argue that simply sending a transaction to the contract binds you to it’s terms, but legally a user must always be informed where the terms are, even if acceptance is assumed upon usage. In blockchain, there is no native client i.e. multiple clients can be created to work with same smart contract.

So how do we ensure that both parties were presented with terms and better still accepted them? One solution we thought about is to borrow from API usage. Typically you need to request an API key to use the API, and as part of that process you are presented with terms and your acceptance is recorded. 

Same can be done with smart contracts : off chain you log on to smart contract’s website and request API key and accept terms, and then add that key to your blockchain client (wallet) which passes the key with each transaction.

collateral risk

In our use case crypto cash smart contract owned by some commercial bank with one-to-one fiat backing in a national bank is used to clear and settle the swap. You could argue that there is very little risk here as central banks in principle have little chance of going bankrupt. 

However, what happens if the money that is used somehow becomes tainted? Most countries have laws and regulations that enforce for instance anti-money laundry (AML) policies.

The easiest place to enforce those policies is in the crypto cash smart contract code e.g. before allowing a cash transaction between two parties, check if the receiver happens to be in an embargoed jurisdiction by calling a smart oracle. This also means that KYC and digital identity will need to solved for on-chain transactions.

Now lets imagine that that the FX swap smart contract holds money that initially was not tainted but becomes so by police or judge whilst it is holding it in its custody – unlikely but could happen.

Whilst there is little central bank default risk, there is still risk that money may become frozen as it has been asset-seized. In this case transaction tracing and conversion law could be used, but it only applies to property. Some countries view virtual currencies as property, others don’t yet have a view. Not sure at all if same will apply to asset backed crypto cash.

crypto technology export laws

As an aside, export of crypto technology is forbidden to certain jurisdictions. Technically therefore blockchain cannot thus be used in some countries. An interesting side case exists – focus of law is on encryption aspect of crypto technology, but blockchain uses it for signing only, so could export laws be relaxed for blockchain?

legal and code layers

Final thought, it helped us to think in layers, there are legal layers, and code layers – the two are separate but in court would be viewed holistically.

No one has yet gone to court and tested legality of blockchain transactions, maybe cheeky, but it was proposed that someone perhaps needs to refuse a fiat settlement of a small FX swap to force the issue in court?

Seven Billion Currencies

Chris Gledhill introduced a fascinating idea at the Digital Currency Summit – in the future everyone could be issuing their personal currencies thanks to significantly reduced costs of running them using distributed ledger technologies.

Currencies obviously play a crucial part in any value exchange system – far beyond just payments, so I wanted to understand the implications of his thinking. It took me a couple of weeks to digest this concept, but now I am ready to share my thoughts on the subject.

I decided to study currencies as a platform business model. On one side you have the currency issuer and on the other you have the currency user. Each party has to benefit in order for the platform to work. So personal currencies will need to have a valid business model to prosper.

I took a broad view when looking at currencies, including fiat currencies, all forms of alternatives currencies, loyalty programmes, vouchers etc.

• fiat currencies – US Dollar, British Pound, Swiss Franc
• local currencies – Bristol Pound, WIR
• virtual currencies – Amazon Coin
• digital currencies  – Ven
• crypto currencies – Bitcoin
• loyalty points – Nectar, Avios (Airmiles)

The benefits gained by the currency issuer were not obvious to me at first, but Chris pointed out that they are able to set their own interest rates, print new money, exercise QE etc. and thus generate wealth for themselves if they are careful not to devalue their currency through inflation caused by high interest rates or over supply of money.

Currency issuers can create wealth for themselves or at least borrow money cheaply by simply printing more of it.

So what about currency users – what is the benefit to them of using the currency? At least with gold backed currencies you could swap paper money for gold – an asset, but when fiat currencies took over, what do you get for your money? Why do people give up ability to create own wealth by becoming their own currency issuers and instead use someone else’s currency?

I took a look at most widely used currencies, fiat currencies, and their issuers – governments, to see if they offer something unique. I realised that they are both huge consumers and providers of goods and services, and they tend to conduct most of their business in the currencies they issue.

According to ONS, there are 5.7M public sector employees in UK earning an average of £574 per week – thats £170B paid out each year.

Not only do governments have direct means to force use of their currency by being huge buyers and sellers of goods and services in their own right, but they can also do so indirectly e.g. laws can force merchants to accept payments in fiat currencies as long as they wish to trade within a specific jurisdiction; industry regulation can place further conditions on terms of trade.

Governments also have a unique capability as compared to private individuals and organisations who may think of issuing their own currencies – they have access to police and army to enforce their laws and policies.

All this means is that the benefit to the currency user is access to a trusted and liquid value exchange market i.e. they trust that they will be able to buy a wide range of good and services today and in the future using that currency; and for that they give up opportunity to generate wealth themselves by issuing own currency.

Currency users give up opportunity to generate wealth through issuance of own currency in return for access to someone else’s more liquid and trusted value exchange market today and superior ability to preserve their wealth by owning the currency for future spending.

For instance, US Dollars are world’s most widely used currency, and it also happens to be that US is world’s largest economy, with a very large public sector and a huge military capability.

Governments use currencies to monetise their ability to create and maintain liquid and trusted value exchange markets.

In other words, governments can generate their own wealth through their ability to create and enforce a stable market for value exchange by simply printing more money out of thin air. No single individual or organisation today has the same mix of capabilities to rival a government, so does that mean alternative non-fiat currencies are doomed?

I think not. I think there can be reasons for becoming a currency issuer other than monetisation of your ability to create and maintain liquid and trusted value exchange markets i.e. there are other business models that do not compete with governments.

Some issuers are using currencies to promote some sort of agenda e.g. local currencies like Bristol Pounds and WIR try to stimulate local economies by limiting where money can be spent e.g. prevent spending on imported goods with earnings from local trade. The benefit of narrowing your market then is that in return you are more likely to get more local business yourself.

Local currencies narrow your market but in return improve chances of securing local business.

There are also social benefits to restricting where and on what money can be spent. In countries where state provides monetary support for essentials to struggling individuals and families, there are cases where those individuals spend all the money on unintended goods and services, and then go back to the state and ask for more money to spend on housing and food, which is often difficult to refuse.

Loyalty programmes, vouchers and virtual currencies also have local but non-geographic agendas. They tend to be local to some ecosystem e.g. to an organisation or even a game!

The issuer in some cases gains insights into purchasing patterns to sell more goods to the customer and in return offers loyalty points that can be redeemed for goods or discount on goods.

If the issuer strikes deals with other merchants to accept their loyalty points, they can often further amplify their value by getting the merchants to agree to discount those goods, thus offering rewards for data at a lower price point for them.

Merchants in return know that those points can only be spent on a narrow set of items, hence vastly improving chances that they will be spent with them – so what they are really doing is offering a bulk buy and marketing channel access discount.

In other cases the retailer offers refunds above and beyond statutory rights in order to differentiate itself from competitors without discounting, but by refunding in its own currency or voucher they ensure the money is still spent with them in the future, whilst the customer gets a refund where otherwise they would not.

Another use for loyalty programmes is to provide a discount option to encourage future purchases using a phycological prompt, often at a cheaper price point than a straight forward discount. Someone with Airmiles is more likely to fly somewhere on a whim, often topping up Airmiles with fiat money – thus spending money with airline where they would not have otherwise.

Alternative currencies are not doomed, and can co-exist with fiat currencies, because in essence they have different business models.

This brings us to Bitcoin. It’s business model is unlike any of the ones above. It’s issuance is not backed by a government or organisation and it has no local, data capture, brand loyalty promotion or discount agenda, so it has no guaranteed market in return for issuer’s monetisation opportunities.

Bitcoin relies on the local to global economy paradigm shift, where an increasingly global economy will demand a global currency.

The hypothesis is that a currency like Bitcoin is so much superior to fiat currencies in a global economy scenario, that all participants will make use of it either exclusively or alongside existing fiat currencies, even if value exchange market is in principle less guaranteed under Bitcoin than it is with a fiat currency.

In return you get access to a much bigger market, local interests cannot override global ones as they do now for those nations that use US Dollars for international trade, and participation costs are reduced as in principle you will not need to pay intermediaries for FX or infrastructure, as the technology rails are superior.

The argument thus is that technology and global advantages will override local ones and out compete the current fiat currency business model in some or all use cases, heralding the rise of global crypto currencies.

In my opinion, all of the above business models may survive as they address different needs with varying degrees of success. This means that we are likely to see a proliferation of currencies to meet ever increasingly niche use cases, especially as the cost to an individual issuer of creating and managing a new currency using distributed ledger technology has dropped significantly.

Does this mean we will see a rise of personal currencies – perhaps, but at this point I am not seeing the business model niche for such currencies. They neither address globalisation in any significant way, nor have the backing of state or large organisations with all of the advantages that they bring. Looking forward to alternative views!

Final note, as a result of this research, I think many loyalty programmes and local currencies, especially when pegged 1:1 to a fiat currency can be implemented better and cheaper if the fiat currency could have restrictions placed on how it can be spent as part of the transaction. That will be the subject of my next blog!

Transaction Privacy

I had the privilege of being invited to present at the Digital Currency Summit held in Madrid this week, which meant that I was lucky enough to listen to a great line up of speakers and panel members debating everything and anything about digital currencies.

One of the themes that peeked my interest was the idea that Bitcoin transactions were superior in terms of data privacy than credit or debit card transactions because you only need to pass back to the merchant your public key.

With credit and debit card transactions not only do you pass on your account details, but also your name and other personal data. Hence you need to trust the merchant to store that data safely, an issue that the European Commission is interested to explore within an overall data privacy context.

The idea of greater data privacy and not having to trust a merchant to keep personal data safe is appealing, but what I can’t figure out is how you avoid passing over data such as your name and address back to merchant in order to arrange goods delivery.

Just because you avoid passing personal data as part of the payment transaction, pretty much the same data will have to be supplied to the merchant and passed on to the delivery company.

One possibility is not to send the delivery address and name to the merchant at all, but direct to the delivery company, possibly encrypted with the delivery company’s public key, meaning only they will be able to decrypt it.

This way the delivery company picks up goods from the merchant based on transaction ID, then looks up in it’s own database the delivery address associated with that ID.

Not a perfect solution, but it does mean that the merchant does not have your address and name and the delivery company does not have your payment data. Be interested how people think this can be solved.

The other feature of crypto currency payments is that they are pseudo anonymous.

All transactions are stored in a public distributed ledger which means anyone can take a look at transactions’ amount, from and to public addresses and comments.

Sounds bad at first, but you must remember that public addresses are created randomly by your wallet and cannot be associated with an individual unless somehow the link between person and public address is disclosed e.g. in UK you have to associate your real identity to a public address as part of the KYC process on a BTC exchange.

However, even if the public address is associated with a real user identity, it is simple to transfer BTC out of your exchange wallet to another wallet you created with a different wallet client. Whilst it’s possible to probabilistically claim that the new address is owned by same owner as the exchange wallet owner, it’s not possible to make a deterministic claim.

In addition, many wallets can use a new public address for each transaction to further obfuscate money flows.This means that it’s possible to figure out how much is being transacted but not necessarily between which two counter parties.

That said, some people have been able to use big data techniques to analyse transaction flows and provide a probabilistic view of which transactions belong to which individual even if a new public key is used for each new transaction.

In fact, this technique is now being considered as a candidate solution for AML on blockchain, as it is a means of tracing the origin of transactions.

The fact remains though, that such an analysis is never going to yield a deterministic view, just a probability which may or may not be good enough. It also does not fully address linking digital identity to public address on blockchain, a must for KYC and pre-requisite for effective AML.

Even if you somehow solve the unintentional association of public address to identity issue, fact remains is that you can see the amount transacted and use that as an alternative way to possibly associate transactions with people or organisations e.g. if in the media it is announced that company A bought another company B for X amount using bitcoins, you would be able to find that transaction on blockchain and associate identity with public address.

Once you associate identity with public address, you can trace what else that company bought, which may or may not be what that company wants to have exposed. Same applies to individuals.

Plain text transaction amounts are key to network’s ability to validate transactions and reject double spend transactions.

So, is there any way we can make transaction amounts private but still let mining nodes check validity of those transactions?

One option is to create closed distributed ledger networks, and trust that the participant nodes do not disclose the transaction details to inappropriate parties. Such a solution would be possible today, but does require trust in an oligopoly of nodes. Maybe an acceptable solution, but can we do better?

Possibly! There is a branch of cryptography called homomorphic encryption – ‘a form of encryption that allows computations to be carried out on cipher-text, thus generating an encrypted result which, when decrypted, matches the result of operations performed on the plaintext.

This is sometimes a desirable feature in modern communication system architectures. Homomorphic encryption would allow the chaining together of different services without exposing the data to each of those services, for example a chain of different services from different companies could calculate 1) the tax 2) the currency exchange rate 3) shipping, on a transaction without exposing the unencrypted data to each of those services.

Homomorphic encryption schemes are malleable by design. This enables their use in cloud computing environment for ensuring the confidentiality of processed data. In addition the homomorphic property of various crypto-systems can be used to create many other secure systems, for example secure voting systems, collision-resistant  hash functions, private information retrieval schemes, and many more.’ [Wikipedia] 

This means that transaction details such as amount could in principle be encrypted, but still processed by mining nodes, validated for double spend and voted on, without ever knowing what the amount is. To empathise – I have no evidence that this could be done, just a hope that it can be.

It is even possible to execute encrypted code on encrypted data without decrypting it by the processing node and produce an encrypted result that can only be unencrypted by the owner of the private key – which paves the way to have proprietary business logic for smart contracts on a public ledger. Sounds interesting, but maybe useless as part of the value of using smart contracts on a public ledger is ability to read the code and assure yourself of the business logic.

There are alternative solutions being proposed too. There is http://zerocash-project.org/, https://www.dashpay.io/ and http://bytecoin.org/ to name a few. They all attempt to solve the problems described above, however I still do not understand how they do it, and there is much public debate about their effectiveness.

Crypto 2.0 Musings – Deconstructing Trust

My research goal is to understand if it’s possible to reconstruct financial services to serve it’s clients better than today assuming that the following hypothesis holds true : smart contracts on distributed ledgers act as disintermediation of trust agents in value exchange systems. For background reading, see the disintermediation of trust blog.

understand if it’s possible to reconstruct financial services to serve it’s clients better than today

Influenced by the structured ideation approach, I decided to start my research by looking for use-cases where value is exchanged and there are intermediaries mitigating trust issues between counter-parties, in order to first deconstruct the value proposition of trust intermediation and later reconstruct financial services meeting and exceeding trust needs but this time in a distributed and de-centralised manner.

smart contracts on distributed ledgers act as disintermediation of trust agents in value exchange systems

I picked on markets as a place to start as they are where parties engage in exchange of value, and tend to have many intermediaries; and I asked some simple questions like:

• what if we achieve same market results but without central services like LSE, LCH, Uber, Airbnb and eBay?
• so what would be better under this new regime and would it better enough to make the change worthwhile?

To answer the first question, I started to de-construct the value proposition offered by marketplaces and central exchange, clearance and settlement service providers. So far, I have ended up with three very high level capabilities that seem to facilitate trust today:

• notarised ledgers keeps track of what has happened in a way that is hard to dispute by counter parties.
• execution flow performs all the necessary steps involved in an exchange of value e.g. clearance, KYC, AML, regulatory reporting, settlement.
• group communications that is reliable and secure allows counter parties to discover and trade with each other.

These three seem to have stood up to a very small test set of use cases I have applied to the model. This model obviously needs huge amount of refining and I suspect will look very different once finished, but it’s a start.

I intend to use this as a test when reconstructing market models using Crypto 2.0 building blocks i.e. does the new model satisfy these three needs significantly better than the old model?

A useful by-product of this approach is that it helps to identify market intermediaries, even when they are not apparent. When modelling current state of a market, if you have not found one or more intermediary that satisfies all of the needs above, you have probably missed one!

Buying balloons and coffee with Bitcoin

Before I started my research into distributed ledgers and smart contracts, I wanted to get a feel for the end user experience of transacting with Bitcoin, it being by far the most popular crypto currency in the world, based on market capitalisation – even if I think the future is more about Fiat currencies and other forms of assets over blockchain like networks, see my Distributed Ledgers and Disintermediation of Trust post.

My goal was simple, I wanted to buy something online – balloons for my kids, and something in a shop – coffee for myself, and pay for it all with Bitcoins. In case it may be of interest to anyone, here is how I got on.

Time – 0 minutes from start

To spend Bitcoins, I had to get some! I had a few options: set-up a mining rig and hope to mint some new coins, buy some bitcoins with pounds via an on-line exchange, or find someone with Bitcoins and exchange cash for BTC.

I chose to buy some BTC via an on-line exchange and ended up choosing a British service called CoinCorner, which offers exchange, payments gateway, mobile and web wallet, POS and other Bitcoin, Dogecoin and Litecoin related services. Please do not take this is a recommendation, it is a service that I found within 15 mins of research that met my needs, that’s all!

Time – 15 minutes from start

To set up an account I had to upload via their website a photo of my driving license, and a copy of a utility bill. I used my phone to take a picture of my driving license, and downloaded my latest phone bill from BT’s website. I also installed their client on my smart phone.

Time – 20 minutes from start

I was informed by email that it would take up to 3 days to do the KYC checks, but within 2 hours the co-founder emailed me asking to email back a selfie showing my face together with the driving license. An hour later, the account went live.

Time – 200 minutes from start

With the account live and kicking, I needed to deposit some GBP funds into CoinCorner holding account, using one of these two methods :

• Bank Transfer – free but takes 2 to 5 working days, minimum deposit £20, no maximum; or
• Debit / Credit Card – instant but has fee of £2.50, also £20 minimum, £1000 maximum.

Being impatient, I chose to use by credit card – a minute or so later, and £2.50 poorer, I had £47.50 in my GBP account. I then exchanged 47.49 GBP for 0.19791666 BTC – so rate of £240 GBP to 1 BTC. Trade completed within a minute.

Time – 202 minutes from start

To find out where I could spend my Bitcoins, I used http://www.wheretospendbitcoins.co.uk/ website for 3 minutes to find an on-line store called http://discountmagic.co.uk and a http://www.nincomsoup.co.uk/ coffee shop. Like before, I am not recommending these shops, they just met my needs.

Time – 205 minutes from start

Process of ordering on-line was familiar i.e. select item, add to shopping cart, etc. but instead of paying by credit card, I choose Bitcoin.

1. A QR code popped up on the monitor, I scanned it with my CoinCorner mobile app and pressed pay button, simple as that!
2. Order was in pending state for just less than hour – standard Bitcoin confirm time, and I got the balloons two days later in the post!
3. Price was quoted as £8.61 GBP, and I ended up taking the FX risk and paying 0.03753 BTC, meaning I paid just under £230 GBP for 1 BTC, or a £10 GBP spread – ouch!

Time – 210 minutes from start

Paying for the coffee was an equally easy experience. The shop also had a Bitcoin ATM, pretty cool!

1. The barrister turned his terminal around, presented me with a QR code just like the on-line one, I scanned it with my mobile app, and the confirm period this time was instant!
2. Again the price was quoted in GBP as £1.60, so I took the FX risk and paid 0.0073 BTC, which means I paid just under £220 GBP for 1 BTC, or a £20 GBP spread – that hurt!

Time – 240 minutes from start

One of the features of Bitcoin, is that every transaction is public, so anyone can see the two transaction that I made. They are pseudo anonymous, since every transaction just shows the public wallet address of sender and recipient, and normally no one can dereference it to me, apart from CoinCorner that is!

But wait, I see I was charged a 0.0001 BTC transaction fee, and was not told about this at point of sale, it’s not a lot of money – about 0.02 USD , but I do want clarity.

It turned out when I read up on it that this is a standard amount, and is charged on complexity of transaction, not amount transacted i.e. it would cost me the same to transact 0.01 USD and 1M USD, but if you create escrow or multi party unlock (multisig) transactions, then cost goes up.

So, in about 4 hours, I was able to buy balloons on line and a coffee in a shop 10 minutes walk from me. What I did I make of all this?

I though that the user experience was actually great, I got going really quickly and both on-line and in-store payment was quick and easy.

But … I did not like that

• Each store quoted prices in GBP, leaving me with the FX risk, and Bitcoin is highly volatile, plus exchange charged me up to £20 GBP spread, and £2.50 for the initial deposit – way too expensive IMO.
• I was not told upfront about the transaction fee.
• Anyone can see my spending, if they figure out my wallet ID, and whilst you can change it every time, it makes me think it’s still possible to trace probabilistically my spending.
• KYC / AML seemed trivial on account opening.
• Online merchant did not appear to have controls, unlike bank and payment merchant rails, to check if money came from KYC verified Bitcoin wallet, after all other countries do not even insist on KYC / AML checks for Bitcoin exchanges. Appreciate cash suffers same issues.

One last thing. You may have heard about the failures of Mt. Gox and other web wallet / exchange systems. I did a bit of digging, and discovered an interesting fact.

All of the widely reported incidents were linked to service providers who provided centralised web wallets or money exchange capabilities, so failure seemed to be due to bad security of a central service, not with the decentralised Bitcoin network itself – which in my mind made me respect the concepts behind the technology even more.

Since CoinCorner’s mobile app is a web wallet based solution i.e. they keep my private keys, I decided to move my money to a standalone client, where I control my destiny, but of course if I loose the private key, game over!

Note – web wallets are convenient as they hold the keys for you, and manage forgotten passwords to unlock those keys i.e. I am less likely to loose the private key as they manage it for me, but it does mean they can transfer money on my behalf, or go out of business and not return my key to me. So much more like a bank without all the guarantees.

I ended up downloading Breadwallet – an iOS app that stores your keys directly in the mobile app, so no one but you should be able to transfer your money, but if you loose the private key, you will also loose your money. It connects directly to the Bitcoin network, unlike CoinCorner which calls via web service calls to their server, which in turn connects to Bitcoin.

As some companies block bitcoin ports, you may be unable to use Breadwallet or like it app inside a firewall’ed environment. Transfer was easy, I just used the Breadwallet app to show the wallet QR code on the phone, and scanned that code on another phone using CoinCorner app.

That’s all folks!

A Better Ideation Process

I have been involved in digital disruption led innovation and technology research for over three years now and have looked at not just specific technology innovation topics, but also at the process of innovation itself – my previous role involved running all the developer and distribution tools and processes, so I ended up being a bit of a process design geek e.g. waterfall, RUP, DSDM, ITIL, PRINCE2, XP, Agile.

I have read countless books and blogs on how to do innovation within an enterprise, some recommendations

Process of Innovation

• Making Innovation Work
• The Little Black Book of Innovation
• The Art of the Start

Innovation Strategy

• Blue Ocean Strategy
• Leapfrogging: Harness the Power of Surprise for Business Breakthroughs
• The Mobile Mind Shift
• Digital Disruption

Ideation Process

• Value Proposition Design
• Business Model Generation

And having read all of them, I was still none the wiser on how to actually do idea generation in a structured way. Sure, you can do structured ideation using themes, campaigns, capture and vote on ideas etc. but all of this is still dependent on someone having that shower eureka moment – i.e. idea origination appears random. For a while I thought this was just how it was – you could not engineer eureka.

Lately though I have formed a hypothesis that whilst it’s not possible to codify eureka generation, it is possible to take the next step towards a more predictable ideation process.

Here is what I am thinking. First, you need to create a business model of your business, and the model of the market that it operates in.

model your market and business

You can use a tool like the Business Model Canvas to model your business.

Also consider using the Strategy Canvas tool to compare your business to your competitors.

Once you have a good understanding of your current state, decompose it into core needs and features graph.

decompose your business to core needs

Here is an example of a super simple example graph for a trading business.

You can use something like a SWOT analysis to start decomposing your business, based on what you have modelled with the Business Model Canvas and Strategy Canvas.

Also consider using the Value Proposition Canvas to decompose your business into pains and gains.

Next, you need to start monitoring technology innovation. You may wish to consider taking a conventional approach and start using research vendors like Forrester, Gartner, z punkt, ThoughtWorks; or you could also explore use of big data text analytics tools like Quid.

monitor and decompose technology innovation

As you identify technology mega-trends e.g. social media, decompose them into core needs and features, just like you did for your business and market. Here is an example.

Now, you should have two graphs, one for your business and market, and one for the technology mega-trend you are researching.

merge graphs and look for connections

Time to merge the two graphs and search for connecting paths. Take a look at the example below:

We have merged the business of trading and social media to come up with a new business model based on the existence of a join i.e. social trading. Obviously this is something that has been done before, so an easy demo of the approach – take a look at BUX.

Could you use it to find a brand new business model? Not sure yet, but willing to test it! I suspect the real dark art will be in the way you decompose the business model and technology mega-trends. Also, this approach may never come up with a revolutionary “random mutation” idea, but it may help with the other 99.999% of ideation.

Finally, just because you have an idea – the what if, you need to test it i.e. the so what? Is it viable, somehow better than current state, can be monetised etc. You can use either the business model canvas to validate the hypothetical scenario model, or the lean startup canvas.

Hope this makes some sort of sense, and love to hear your thoughts on this.

Crypto 2.0 Musings – Scheduler and Scoping

In order to get my hands dirty with smart contracts, I decided to try my hand at smart bonds. They are an interesting asset class in as much as they have a long tail – once you have sold a bond, you then have to pay coupon payments for a long time. Automating those payments could in principle achieve operational costs savings. Frankly, could have chosen any other instrument, but you have to start somewhere.

I roped in Ian Cusden to do the actual coding and a few other guys to give us pointers on how bond business logic works. We chose Ethereum as the smart contract platform to have a go with first. It’s our intent to do the same exercise in the future on other platforms likes Eris Industries, Ripple’s Codius etc.

After a couple of week’s worth of on/off work we have something that kinda works – very exciting. We created smart contracts to represent a virtual currency, a smart bond and a Libor smart oracle. We knocked up a simple web UI to issue new currency and bonds, and buy/sell bonds in exchange for virtual currency. We implemented a simple state transition for bonds to simulate issue, allocate etc. transitions.

no mechanism for a smart contract  to issue coupon payments in the future

And then we hit a problem. We have found no mechanism for a smart contract  to issue coupon payments in the future. It appears that both Ethereum and Eris (have not checked others) do not have a scheduler mechanism – a smart contract must always be pinged by either an external call or by another smart contract.

There is of course a work around, you can have an external scheduler pinging smart contracts like a clock, but that’s not very elegant. I would much prefer if a smart contract could be programmed to wake up in the future and do something, or at least issue a transaction to itself for a future date i.e. a forward transaction, and processing nodes would only process those transactions when the time is right.

what should be part of a smart contract and what is out of scope

Apart from the scheduler issue, we also ended up thinking a lot about what should be part of a smart contract and what is out of scope and to be implemented by something out-of-band.

Thinking is very raw at this point, but if I was pushed for an opinion, I would suggest that one should focus on business logic of trust to be implemented as a smart contract and other parts can be out-of-band.

Let’s use an example. When a bond is issued and people allocate money to it, I need to trust that I will get some or all of my money back if the bond is over allocated. So the process of sending money to the smart bond and issuing refunds in case of over allocation must be implemented as a smart contract on a distributed ledger, to ensure trust of execution.

On the other hand, as a bond or currency holder, you will want to know how much money and what bonds you hold. As bond issuer you will want to know how many you have issued and possibly bond holders. So, all of that user centric data pivots and UI to issue new bonds, state transition them etc. are suited for implementation  in a desktop or web wallet.

If you were to create a secondary market for these smart bonds, then you would want a way to discover bonds for sale and provide a capability to offer bonds for sale, request purchase of a bond, and then actually buy and sell bonds. At the very least then you would some sort of a search and analytics engine to enable that.

Ethereum for instance does not have an in-built register of smart contracts, but it does have a name registration contract that could act as a directory. Even so, ability to easily search and find a smart contract and its instances is limited, and would be better implemented as as a search engine with a visualisation layer, to visualise both bond contracts and understand transaction flows.

There are parallels to this in Bitcoin – businesses like blockchain.info have sprung up to partly help view and analyse transactions. It helps to only track a single asset – Bitcoin. It gets more complicated to do the same when you have many different assets as you can with Ethereum and others, so more sophisticated tools will need to emerge. Currently we are thinking of using ElasticSearch and Kibana to help visualise our flows.