Monthly Archives: August 2015

Standard

Posted by

Posted on

August 26, 2015

Posted under

advice, architecture, blockchain

Comments

18 Comments

Free advice can be valuable… but only if you take it

If a client tells you your solution doesn’t solve their problem, it may not be the problem that needs to change…

I often argue for the importance of blockchain and distributed ledger technology by using the following chain of logic:

  • Bitcoin’s architecture solved the problem of censorship-resistant digital cash
  • But few, if any, financial firms are interested in censorship-resistant digital cash
  • So why are they looking at this technology?
  • Because some principles underpinning Bitcoin’s architecture – shared ledgers, for example – could be relevant to problems that banks face.

Sure, a blockchain or a replicated shared ledger could indeed be useful to banks. Perhaps it could reduce the need for reconciliation between firms if they all ran off a single ledger, for example. But this says nothing about whether blockchains are the optimal solution to any particular problem in banking.  That still has to be argued, of course.

Recall: the bitcoin architecture was a solution to a very specific, very carefully framed problem – how to transmit value without the risk of censorship. Just because the underlying architecture could be used to solve some pressing problems in banking doesn’t mean it’s the best way to do so. Indeed, although the interlocking aspects of the Bitcoin solution are in some ways quite elegant, there are also some compromises. After all, it is an engineering solution to a set of very specific constraints and so it has to be demonstrated that it’s the right solution when the constraints are different.

Lee Braine, of Barclays Investment Bank CTO Office, made an important contribution to this debate when he spoke at London Blockchain Conference 2015 recently.  The video is now available and I urge anybody working in this space to watch it and to internalise its message.

[vimeo 137190236]

We all too often “talk past each other” in the distributed ledger world and we are quick to assume the other person just “doesn’t get it”.  I can assure you that Lee does get it and it would be a brave startup in this space that chooses to disregard what he said. He’s giving us free advice! Take it!

Like I say, watch the video for yourselves.

I think another way to capture the chain of logic in the video is as follows:

  • Assume the ongoing interest in the application of blockchain technology continues
  • Assume further that some banks identify some compelling business opportunities in deploying a cryptographically-secure shared ledger between themselves.
  • What is the probability that a derivative of Bitcoin or Ethereum or any other current platform will be the best solution to that specific problem?
  • Given that none of them were invented to solve that problem, surely it’s quite low, right?

So we could find ourselves in the situation that bitcoin and blockchain technology have catalysed an orgy of activity, that this activity has identified countless high-quality business problems and yet none of those opportunities are best addressed with the technology that triggered the excitement in the first place!

The theme of this blog is “free advice” and the free advice I’m taking from Lee’s comments includes:

First, we shouldn’t get enamoured by a particular implementation of a technology. Sure: if you have an implementation then you may have bought a place at the table.  But don’t make the mistake of assuming that if the business problem doesn’t fit the technology then it’s the business problem that needs to change!

Secondly, if you’re working in a financial institution, be careful to distinguish between the principles embodied in these technologies. Shared ledgers? Yes. That seems to be at the heart of this domain. Indiscriminate replication? Perhaps. Cryptographically-secured access down to the “row” level? Probably. And so on.

Thirdly, consider the complexity of banks’ existing IT environments. An idealised, “wouldn’t the world be perfect if…” solution is no use to anybody if it requires the whole world to move at once and/or if there is no credible migration path.  This points to a need to listen to the incumbents when they object.  Furthermore, consider the non-functional requirements which are simply a given in this space.

Fourthly, if we assume that today’s current hyperactivity will lead to a new understanding of the possibilities for banks but don’t assume that today’s blockchain platforms (permissioned or permissionless) are the (whole) answer, then surely we’re back in the land of engineering, architecture and hard work? Perhaps this means that the combination of persistence, data models, APIs, consensus, identity and other components that we need won’t all come from one firm.  So a common language, some common vision and an ability to collaborate may become critical. Where is your distinct differentiation? Where would you fit in an overall stack?

Standard

Posted by

Posted on

August 17, 2015

Posted under

Bitcoin, bitcoin xt, block size, governance

Comments

148 Comments

Brief thoughts on the Bitcoin block size debate

I’ve kept well away from the block size debate but the launch of Bitcoin XT is worth a quick mention.

My reasons for staying out of the debate are pretty obvious: I’m not a miner, I’m not a core developer, I don’t run a wallet service, I have no particular insight into the engineering trade-offs and, perhaps most importantly, I’m not mad. If I wanted to argue with people on the internet, there are far more interesting topics than Bitcoin’s block size…

But I’ve been asked by several people what I think.  And, at core, I think it might come down to three issues: 1) fear of two different types of failure, 2) a clash of visions and 3) no process for reconciling the first two issues.

Fear of Two Different Types of Failure

Fear of technical failure

I don’t contribute, but I do read the Bitcoin Development mailing list.  I find it immensely helpful in keeping up with much of the day-to-debate debate.  What becomes clear when you read it is that there are (at least!) two distinct cultures at work.

First, there is a very strong security engineering culture. I sometimes think the trick to being a good security engineer is to think like a software tester (and vice versa): “How could I break this?”… “How could an attacker get round this?”… “What could go wrong here?”… “How could I force the provider of this service to waste all their resources”  And so on.   Your job is to figure out all the ways something could fail, and fix it.

So, when presented with something like an increased block size, you obviously focus on all the things that could go wrong: miners on slow connections could get out-of-sync with those on the other side, the increased cost of running a node could create a centralisation pressure and so on.    And when you compare this against the potential benefits, you might not think the change makes sense:  there’s an increased technical and security risk but you haven’t fixed the underlying scalability issue at the heart of the system… you have, in some ways, just kicked the can down the road. So you might say that a driving issue here is “fear of technical failure”: the change, which has uncertain benefits, could cause catastrophic harm.  Better not do it just yet.

Fear of practical failure

But, on the other side, is a somewhat different culture, one that comes from a world where there are problems everywhere you look and they all need fixing.  So you pick the biggest one, fix it and move on.  The engineering functions of large companies are often like this.  You know your change might cause problems but if you believe “doing nothing” is not an option then it comes down to making the least-worst decision.  There are, after all, usually no good solutions, just compromises.

So, if you’re faced with a problem like blocks getting full in some foreseeable timeframe, it is natural to ask yourself: what is the risk of doing nothing? If your belief is that consumers mostly have choices and will simply abandon a system that can’t guarantee transaction confirmation in a reasonable period then you’ll likely see failure to increase the block size as something that will lead to a catastrophic exodus of users and your bias will likely be towards making the change.  For you, the issue is “fear of practical failure”: failing to increase the blocksize, a change which has uncertain risks in any case, will drive away users and make the system a failure in all practical cases.

I exaggerate for effect, of course and I’ve ignored many aspects of the argument (e.g. the fee market, etc). And I’m sure some of the details are simply wrong.  But note: even under this simplistic model, it doesn’t mean either side is “wrong” or “bad”: it is possible to hold either view quite legitimately and to passionately believe the other side is wrong

A Clash of Visions

Where it gets more complex is when it comes to vision: if there was common agreement on what outcome was desired (e.g. “x transactions per second across the blockchain by 2017” or “the system should support this number of consumer wallets”) then the discussion would be a pure engineering discussion: “what is the best way to achieve this goal?”  But it strikes me that there isn’t agreement on this underlying vision.

And so, the engineering discussions get lost in the sound of people talking past each other or, worse, resorting to ad hominem arguments.  If you’re arguing from different premises, you never get anywhere, sadly.  It’s what makes political discussions on the internet so tedious..!

Process

In most projects, these issues can be resolved, ultimately, through the “benevolent dictator” model. Linus just decides.  Unfortunately, that process just doesn’t work in a system like Bitcoin. It’s not enough to control which code goes into the “core” distribution: the prevailing network rules are a complex function of miner adoption, full node adoption, wallet adoption, major merchant/processor adoption, and more.  It’s an inherently messy and political process. So the block size debate is likely to just be the first of many such controversies in this world.   The launch of Bitcoin XT is an interesting way to force the debate towards a conclusion but it’s likely to be messy.

And I hope those looking at “private blockchains” aren’t feeling smug as they read this. Managing the maintenance and upgrades of shared ledger systems between firms won’t be a walk in the park, either.

I have no particular insight into where this will go or which vision of the future will prevail.  But I hope (perhaps forlornly) that it will be resolved through the actions of professionals acting in good faith and that neither side will resort to “dirty tricks”.