Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Ian Grigg: Ricardian Contracts and Digital Assets Prehistory

Episode Date: October 3, 2016

Before 2013 few people paid attention to Bitcoin and blockchain, yet even back in the 1990s a vibrant group of prioneers pursued the vision of financial cryptography and digital cash. One of these was financial cryptographer and software developer Ian Grigg, who today works as an architecture consultant for R3. Grigg joined us for a discussion of the history of the digital cash, Bitcoin and his work on Ricardian Contracts, which foreshadowed today’s smart contracts. Topics covered in this episode: The origin story of financial cryptography DigiCash and the startup scene around it in the 1990s Ricardian Contracts and why contracts are central to digital assets Ricardian Contracts vs blockchain Episode links: Ricardian Contract Paper Financial Cryptography Website Financial Cryptography in 7 Layers R3CEV Brown, Carlyle, Grigg & Hearn: Corda - An Introduction This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/151

This is EpiCenter episode 151 with guest Ian Grigg. This episode of Epicenter is brought you by Jax. Jacks is the user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to JAAWX.I.O and embrace the future of cryptocurrency wallets. And by the Bitfinity Conference taking place in Miami Beach from October 30th to November 2nd, join industry thought leaders, investors, and leading blockchain companies to discuss and showcase how they use blockchains a wide range of industries. Go to Bitfinity.com slash Epicenter for discounts on registrations and exhibitor packages. Hello and welcome to Epicenter, the show which talks about the

technology projects and startups driving decentralization and the global cryptocurrency revolution. My name is Brian Fabian Crane. And I'm Meher Roy. Today we have a very special guest, financial cryptographer Ian Grigg. Ian is known for his work with Ricardian contracts and is long and broad knowledge of the cryptocurrency and blockchain space. So we'll be talking all about topics such as how did shared ledgers originate, what are the accordion contracts, what they can be used for, and the future of the merger between smart contracts and the cardian contracts and technologies such as smart legal agreements. So before we start, let's have a short introduction from Ian about his background.

Ian, can you tell us a bit about your background and how? you got interested in merging cryptography with finance? Sure. So I was a systems programmer by trade way back when. And in 1995, I was sitting in finance classes, I was doing an MBA because I was bored with life, so I thought, you know, I'll do something interesting, sitting in finance classes learning about zero coupon bonds. and while I was doing this over in Amsterdam, an old programming mate of mine, Gary Halvand, was working for a company called DigiCash,

and they had invented the new way to put money onto the internet. And at the time, this was radical, because Netscape had just gone through its IPO in 94. The web was booming. E-commerce was going off like a rocket, but everybody was turning around saying, where's the money? And the money was in Amsterdam. DigiCash had invented the digital cash to power the new economy.

So this was very exciting at the time. It was a huge hype bubble. And Gary was feeding me all this information from DigiCash about how it was working, what the technology was, read the articles and so forth. And I was sitting in finance classes looking at zero coupon bonds. And I realized a zero coupon bond. was exactly what they'd invented in Amsterdam.

And the thesis that they were presenting in finance classes is if you understand the zero coupon bond, you can build any instrument. And I realized that DigiCash had their horizons too narrow. That was my feeling at the time. They were thinking about money, but far more interesting instruments out there, shares, equity, bonds, derivatives, and so forth.

all of these, all of finance, could be implemented using this technology. So that's, so basically talking to Gary, we decided to give it a go to put all of finance onto a ledger arrangement. I don't want to use the word distributed ledger yet. So that's how I got interested in finance classes. We brought together those two and then moved into building it. Can you say a few things about how DigiCash actually worked? How is that different from Bitcoin?

So everybody then was thinking client server. It was the only way to think, really. There was no peer-to-peer. Peer-to-peer hadn't been invented until there was another five years coming, 1999. So what DigiCash were about, David Chalm was a privacy advocate. He spent a lot of time as a cryptographer, a real cryptographer. doing real cryptography to preserve privacy. And his notion of money was based on the metaphor of the digital coin or the hand-to-hand note.

And this has the property that when you and I change a note over for some, you know, a drink or groceries or something like that, this is a final transaction, firstly. And secondly, it's an untraceable transaction. It's also anonymous, which is the word that is typically used. We can go into a shop and neither of us need to tell each other the name. We can do the transaction right there and then, walk away. It's untraceable, it's anonymous, and it's final. His view of society was that unless we do this on the internet,

we will be preparing for a world of mass surveillance and mass control and all of Allwell's nightmare scenarios in his books would come true. So he spent a lot of time working out the cryptography such that a server could issue digital cash to you. You could then give that digital cash to me. And when I get it, I run this special blinding formula, which we have to coordinate, such that it changes the cash to a different form of cash, but it's still, recognizably signed by the issuer, the server. This blinding formula allows the issuer to sign a coin, but that signature can then be morphed by the blinding formula such that it's still recognizably the

signature or a signature, but it's not the same one. So a coin could transfer untraceably from the issuer, the server, to you, to me, and then I could deposit the coin back and refresh it. So DigiCash would issue a coin and then you would have it and you would be able to give that to Meher without having to, you know, ping DigGCash server to change a register or something. You can do that directly and then Mayer has it. Yes. And in the process of handing it over, we'll refresh the... Yeah, and then you don't have a double-spend problem.

Well, the double-spend problem is solved by the receiving party, then having to send the coin through to the server and refresh it for a new coin. Okay, okay. So literally you do have a double spend problem, and that's where the terminology came from. As much terminology came from in the Bitcoin world, it came from prior art. The double spend problem is solved by moving it through the server, refreshing it, and coming out with a clean coin. Because otherwise, literally, yes, somebody can keep duplicating it with different merchants.

this like almost feels like a bit like zcash to it to me because in in zcash you have these public coins and then you can go go through a process and like you can create these private coins and then once you send these private coins it kind of breaks any any linkage from where the coin came from which address the coin came from and which address it went to and what was the amount? So did DigiCash also conceal like the starting account, the ending account and the amount? The coin, once it was out there, had no indication on the outside of the accounts that it came from. However, there was a part of the cryptography is that if you were to then go and double spend the coin that you'd got,

and then the two merchants would both attempt to deposit the same coin. The second one would fail, of course, because the server recognized that it had already spent that coin. However, it would then have two different coins which it could combine together, and that would reveal a piece of information. And that piece of information was the source account. So, in fact, there was another control over the situation. And that was kind of necessary in a formal banking world in the sense that if you're using these things, you wanted to be able to say that the original account holder was to be held accountable for any double spending,

as well as the fact that you wouldn't actually allow it to happen. So what was the advantage of a design like that versus just digit cash having essentially like a blockchain, right, or like an account registry of all the accounts? and now you go and you tell DigiCash move one of my coins to Mayhurst coins. Why would you do it with this coin format that requires this refreshing? Yes. So the arrangement with Bitcoin, which of course is like the standard that exists in everybody's head these days, is that you use a pseudonymous key.

And if you want to spread your coins around, you can just write them to different keys. And this creates a graph of confusion, if you like. It's security by obscurity. And that mechanism was exactly what we used. Gary and I used back in the 90s. We created a pseudonym system whereby if you wanted to preserve some sense of privacy, you would just create a bunch of pseudonyms and swap them back and forth to obfuscate the trail. Why wouldn't you do that?

It was much more efficient to do that, and it is clearly much more. efficient to do that, but unfortunately the long run is that somebody can always analyze your activity. So in theory, DigiCash or the eCash system gave you a perfect out, but that was only in theory. In practice there were two things that went wrong with eCash. The first of which was that everything was tranched into coins. The coins were denominated in a number and that number didn't change. So if you were doing a transaction, for example, you wanted to do $9.99, you needed a set of coins, which matched $9.99. So you could track those numbers statistically and figure out who was moving money around. And secondly, the clients weren't really set up,

or people weren't really set up to hold the coins on their own wallet because of the sensitivity with backups and so forth. So you had this tendency whereby, by, people would just use the account at the bank or the mint. And when they needed to do a purchase, they withdraw all the coins and then send the coins across to the merchant, and then the merchant would deposit them back in to correct, to control for double spending. So consequently, there was both a time and a coin-based tracking mechanism,

which meant that you needed sophisticated clients to pull this trick off, and you needed a lot of traffic before it started to actually develop its its privacy features. And of course, this never came to pass. So back then, you said there was a lot of excitement around this, and there was e-commerce and maybe Amazon and all of that was starting. Why didn't, why did it fizzle out? Why didn't it continue going and gain traction then? What happened? So it's a little bit difficult, and this is unprovable, of course. People who are involved have have basically denied knowledge of any of this. The problem started when DigiCash issued,

I think it was like 750,000 cyberbucks or something like that. Their test currency, their toy currency. This was the first announcement that the open media had seen of this new invention. The invention had been sitting around in scientific papers and cyphepund rooms for quite, some time. But it was the first time anybody could do it. So people started downloading the staff. The open media caught it and started writing articles about this. I think there's a Wall Street article or something like that. Then the central bank picked up on the article to Netterlands Bank, which is in Amsterdam, of course, picked up the phone and called David Shulham and said,

my office Tuesday, 9 o'clock, bang. And in that meeting, which was, Shepard, which was shall we say, not a happy meeting. The compromise that came out of that, the Netherlands Bank position was, don't ever do that again on our territory, because it was extremely embarrassing for them. The compromise that came out of that was Digi Cash agreed to only ever sell to commercial regulated banks. And consequently, if the banks didn't need or want the product, they were back in control. So what happened was a five-year period where DigiCash went around and sold to banks. But if the product wasn't fantastically successful, or if there were rollout problems,

or they realized that actually this had unfortunate circumstances, unexpected consequences, they would back off. And that's what happened. The banks dabbled with it, and it backed off. And then strategically speaking, of course, the banks didn't want to lose control. So they set up a project called Set, I think it was, secure electronic transactions or something. And that was, if you like, a copy of the credit card system designed to do digital cash and literally designed to bring all of the banks back into the fold doing an internal standardized product.

And then they're all able to go around and say, well, we're waiting for set. we're not going with Digi Cash, we'll just do set, which of course was internal controlled and not adventurous. And that kept going and it just sacked the energy out of the field. So Digi Cash was never able to sell into, if you like, an unbiased party that really wanted to make it happen. What about other projects? Was there besides Digi Cash? I mean, you said you were involved in a startup then and maybe there were others or was it really Digi Cash this dominant player? It was dominant because it had the patent for the cryptography. And it wasn't for a few years that enough alternative cryptography surface that allowed you to bypass Digi Cash's patents, which is what I did later on.

When I started, May of 1995, Gary and I agreed to do this. I went to Amsterdam. For two weeks, all I did was market research. And I discovered 20 companies already doing something similar. At that point, after two weeks, I said, you know, enough is enough. I know what they're doing and I stopped. And from then on, for the next five, six years, until the dot-com crash, there were at least 100 companies every year coming out, doing much the same thing over and over again.

So it was a vibrant field. There was a lot of competition, but also it was a repeating field. Everybody was making the same mistakes. and it was out of this that I came up with this concept of financial cryptography in seven layers where just talking to people about the way things worked, the things you needed to understand to get to the end made me realize there are a lot of, if you like, polymath disciplines involved in trying to make it all happen, and there was actually a layering

in terms of the way these intersected together. And out of that came that paper, FC, in seven layers, which when you've read it, again, it feels a bit obvious. But actually, the big message that comes out of that is that really it is too much for one mind to conquer because your specialty dominates your thinking. And you need specialties in those seven fields to be able to build up the knowledge to be able to do it. Let's take a short break to talk about Jacks. Jacks is a multi-coin wallet created by the people at the Central. Now in the past, if he had a whole bunch of cryptocurrencies, it was a pain to handle them. You either had to leave them on an exchange, which was insecure, or you had to have all these different wallets, which was a hassle.

Fortunately, now with Jacks, those medieval days of darkness, misery, and suffering are over. Jack supports multiple cryptocurrencies and new ones are B. being added. But it's not just storing cryptocurrencies you can do with Jax, but you can also exchange them directly from within side the wallet thanks to their shape-shift integration. And since there's only one seed, Jax makes it super easy to back up and sync to the other devices. Jax works with Windows, MacOS, Linux, Android, iOS, and has browser extensions for Firefox and Chrome. So go to Jax.io, that's J-A-W-X.io, to download the wallet and get started today. We'd like to thank Jacks for the support of Epicenter.

We'd like to go into financial cryptography and this idea of the seven layers and the field of financial cryptography as the next theme. But before we kind of close down Digi Cash, I've actually read in various places a different account of the failure of Digi Cash. And I like your opinion on this account. So the account I've read is that DigiCass essentially failed. because it failed to anticipate that credit cards could also be moved to the internet. So when the internet was in its infancy, there wasn't a really good way to put credit cards on the internet. Because like once you have all the credit card data plugged in, like if you're typing in credit card data, then essentially the merchant could spend any amount out of your credit card.

So you needed a way by which credit card. needed a way by which credit cards could come onto the internet and then essentially you think of it as two competing technologies. One, the idea of issuing these digital coins that are anonymous. And one is, hey, we have this credit card network. Let's just plug that into the internet. And out of these two branches, it's the credit card branch that succeeded massive. And this other branch died out until it had a reincarnation later as Bitcoin. What do you think? think of this? Yeah, so as technologists, we seek

an answer in the technology. Clearly, the credit card won, so it's better technology for the game. And DigiCash had flaws, but actually both had flaws. If you go through and list out the floors, they're both equally flawed in various respects, as you pointed out.

My opinion is that it was nothing to do with the technology. It was purely an institutional question. The credit card companies, and the company surrounding the credit card companies had the institutional mass to make it work. And key amongst them was the Netscape and RSADSI partnership, which started out by, started out 94.

They were already on the road at this stage before Digi Cash started building up with this little thing called SSL to try and protect the, the merchant's credit or the credit cards from being snaffled over the net. And that was a very large and institutional play that morphed into the whole VeriSign thing, which became a very rich company based on its ability to control the cryptography that was being used in everybody's browser. So it was, and they weren't the only thing that was going on. There were other things as well.

There was a thing called S-Html. We ended up with HTTP S. Or was it, yeah, HTTP, so the S at the beginning rather than the end. And these two were in competition to try and secure the credit cards. So there were a bunch of competitions going on there. But the ones who won were the ones who had the institutional clout. And Digicash had no institutional clout at all. What it had was David Choram, a patent.

So you're saying that SSL also was invented specifically to solve this issue with credit cards? SSL was literally invented to stop the credit card being snaffled as it traveled across HTTP. That was its precise requirement. Yeah, as in explaining this, it's like if, say, I'm the merchant and Ian is the buyer, and Ian sends his credit card details to me over pure, like, unencrypted HTTP, then anybody who can sniff and listen to Ian's... packets as they emerge from his computer can also learn all of the credit card details and then use those details to spend it somewhere else so you essentially start to need a channel by which the

merchant which is me and ian is the customer have an encrypted channel between them so that the details can only be read by the merchant this is essentially what the https does yes okay so you mentioned before that there was all these companies, a hundred companies working on this problem set back then, and you said they kept making the same mistakes. Do you see some of those mistakes being made again today with all these blockchain, Bitcoin, crypto companies? And what are those mistakes? Lots of them. So, for example, one of the things that is very typical is that companies build up their mechanism, they build up a new accounting mechanism to try and manage their coins or their tokens or whatever it is. And they start off from a position of what we, you know,

euphemistically call single entry, basically a list of values, which is stored in some database somewhere. And the problem with single entry is that if I've got a list for mayor and another list for Brian, to move money, I have to take an amount off the first one, the first list, and add the money to the second list. And I have to do both of those at the same time, and I guarantee that they're not sliced up. And this is basically the genesis or the origin of transactions in databases. The notion that you can do two things at once

and guarantee that either both happened or neither happens, roll back or roll forward. But typically what happened was that the financial cryptography companies would come out there and install a database, which they'd put together MySQL or something like that, and they would just do their own tables, and they would end up moving the money, but there would be two different operations,

one to add, one to subtract, or something like that. And then an attacker would come along and realize that if they could organize a certain way in which they could do it, they could chop the transaction in half and cause money to go up and up and up, and up, and up, and up. And you see this, for example, in the Dow. This is precisely what happened.

the transaction that's in there or the accounting metaphor that is proposed for Ethereum is single entry. And single entry has the weakness that it can always be sliced at that point. So without proper database support, you're always going to have a problem. And consequently, what happens with the smarter companies, the ones that get a bit further down, the line is they get it up and going and discover that they're always losing money. And it also happens just because of crashes and failures and bugs and so forth. So then they go and do a bit more research and discover that the solution is to put in double-entry, double-entry accounting.

So everybody goes through this process. And it's still happening today. Ethereum is going through it right now. Okay, that's very interesting. Now, I want to ask another question on that. So that's a technical flaw. And yeah, you're certainly right, but we've seen that in the Dow, I guess with Mount Cox, maybe there was some of that too.

Yeah, same thing. Same thing. Yeah. But what about the business side? Do you also see, because one of the big issues that Mayhund I talked, for example, the last podcast was that it seems to be that companies struggle a lot to find the business models that work and the user base that works. Yes.

Do you also see, what are your takeaways on that point from back then and what happened back then? And how do those apply today? It's the standard problem. You've got a bunch of engineers who actually have a good idea. And they can build it, but they don't know what to build. It comes from their own particular inspiration. And sometimes you can get lucky that inspiration can actually find a demand. but for the most part, your standard engineers have no particular view or feeling or clue about

business development and what products make it into the market. So you end up with a very haphazard approach. And in this particular lottery, it's stacked well against the entrepreneur. So you'll find that most of the companies that go out there with big ideas will not get anywhere because they haven't got a use case firmly in mind. they don't really know what a use case is. They don't have business development people who can put together a strategy, etc. I mean, often they employ business development people,

but these people are hamstrung right from the start because the engineers won't talk to them. The engineers won't communicate with them and listen to what is out there and what can possibly work. So back in the day, in 1995, there was a big company that got a lot of money, doing essentially Digi Cash stuff. the VCs went in and said, you know what, this DigiCash stuff is crap, it's not going to work, switch across to credit cards.

So they switched across to credit cards, and that's an example of engineers which were forced to listen. I can't remember what the name of it is, but they morphed into a big payment processing operation in the end, just basically doing credit cards. And if you look at, for example, PayPal, PayPal was a digital cash mechanism. It was originally Palm Pilot to Palm Pilot, and you would move coins between, or you do transfers between one Palm Pilot and another Palm Pilot. It was mobile money, literally. Within the year, they had turned off all the mobile money,

got rid of the Palm Pilot, and they were doing basic website transactions. And within another year, they got rid of basic website transactions and we're now doing credit card facilitation. And it's an example of a company that morphs to find where the demand is, which you just don't find with a lot of these startups. Do you have any intuition about where those companies would need to morph or where that kind of demand might emerge? Well, hundreds of intuitions, yeah. This is the startup process, of course.

You can't just sort of come up with a general rule. You've got to look very closely at the circumstances. What's the skill base of this company? And what's the country we're talking about or what's the group of users they're talking about? So there's no generalism here. finding a business product is as hard as finding a cryptographic invention. But do you feel like there is a big area or a big direction or a kind of type of class or problem that will open a lot of opportunities for maybe a company to become really big

or a whole bunch of companies to become successful and thrive? because the way it looks like at the moment from my perspective, so there is the kind of Bitcoin case, right? Bitcoin has become somewhat successful, and it could become very successful, right? You have that kind of dynamic, or something like Bitcoin could become very successful. It's not very clear what else, right? Even if we have Ethereum also these open protocols, But in terms of actual business models, it's very hard to see. Yeah, yeah. You know, and this is where I kind of drift into R3 thinking.

If you've got a context of regulated financial institutions and regulated companies doing regulated business, then you can see a way forward, but it isn't blockchain. It's moving packets back and forth to establish consensus over a shared set of facts. And that's basically what court is designed to do. So that is a different approach. And it's an approach where you can see, for example,

we start back in the middle of last year, we started with the whiteboard saying, what's a blockchain? And gradually, you know, you chop away, you knock off a few letters and you add a few more letters. And the end result is that you end up with something that the companies actually want to be able to do shared workflow.

and establish real hard facts about what they've done, but you've knocked out most of the things that make blockchain what it is. So if you've established that context, then that's a good direction. But what context do we talk about? So, for example, if you look at Bitcoin, it's popular amongst a disparate bunch of people, but all for different reasons. So if you talk about libertarians, for example,

they want money to be able to trade back and forth in their libertarian deals, which is fine. It works for that. But that's never going to be ultra successful because there aren't enough libertarians in the world. It's too small a group. And it has other flaws as well. Then you can talk about, for example, remittances. Now remittances work between small, poor people who send very low value amounts from country to country. Now, that could be very successful, but the problem there is the remittances as a regulated market.

So consequently, you get so far before the regulator turns up with a baseball bat and clubs you. So consequently, it's hard to say where the killer app is. Of course, if I knew I would be out there building it. Cool, cool. Yeah, definitely. If you knew, you would be building it. Today's magic word is Ricardo. That's R-I-C-A-R-D-O. Head over to let's-talk-Bitcoin.com to sign in, enter the magic word and claim your part of the listener reward.

Now we'd like to change focus to the notion of financial cryptography. I think like you run a blog which is called financial cryptography. this paper, which is like financial cryptography in seven layers. You have this article, I don't know the source, but where you say that Bitcoin has managed to unite the financial cryptography community behind a single code base. But before discussing all of this, I would like to have kind of your definition of financial cryptography, what it is and what keeps it going as a field. Yeah, so financial cryptography was a term invented by Robert Hettinger.

He was a cyphepunk from way back looking at the potential for DigiCash as eCash and various of the many other interesting cryptographic ideas in the cyphibunk field. And the observation was that in the sphere that we were interested in, what was important for cryptography was financial transactions. We wanted to do finance. So he put the two together. So financial cryptography is what happens when you apply cryptography to finance. Now, that's in opposition, for example, to cryptography applied to national security

or cryptography applied to privacy. So if your chat program is private, for example, that's not financial cryptography. So we were always looking at the notion from the very beginning, that we wanted to put money, for example, into the financial cryptography field. That was the core starting point. And there was this notion that we could also bring in all of the rest of finance, but that wasn't so well discussed, mostly because we were still in the formative period of trying to work out how to get money up and going.

And if you can't get money up and going, can you get anything else up and going, which is the topic of my work. But as a generalism, people were concentrating on what they could understand, which everybody could understand cash. So let's get cash up and going first. Now, my notion was that, yes, okay, so we've got finance over on the left and we've got cryptography on the right. But there's a whole lot of stuff in between. This accounting is a real killer. If you don't understand it, you end up doing single entry, for example.

And then there's a notion of rights, which is a very complicated. and not particularly well-understood field. We see people talking about it a lot, but it was really only developed to an extent by one particular school, which is the capability school. And it's information, the concepts didn't really flow into the rest of the field. And then, of course, there's software engineering.

Most people seem to think that cryptography and programmers are interchangeable, but they're not. They're completely different disciplines. and there's very few people who cross over to the two fields. Zucco, for example, is one, who is both a cryptographer now and a programmer. Essentially, however, programming is such a unique field that unless you have seriously good engineers

putting together this seriously complicated code, you're going to end up with, well, basically a mess, and that's what happened with a lot of systems. So, for example, there was this system called EGOL, which I had a fair bit to do with, not my company, but not my code. The guy who put it together was very, very smart. He taught himself to program. He was a radio oncologist.

He was a doctor. He wasn't actually a programmer at all. He taught himself to program, and he wrote the whole thing in SQL Server. Now, he got it up and going, which is pretty damn amazing for somebody who's not a programmer. But the mess that was in there was. really took them ages to get through to clean up. And I'm not even sure they ever got through and cleaned it up. So you had this difficulty of trying to get all these disciplines together.

And consequently, out of that came this paper that basically said, okay, if you're going to do this, build a team of seven people, please. And what are these seven disciplines? What are these seven layers? What are these seven people, seven skill sets? So you've got your cryptographer. Now, to a large extent, you don't actually need a cryptographer and you don't need much cryptography. You just need to understand it.

Then you've got your programming department, and that's the one where most people understand. Okay, you need some programmers. But you also need somebody who understands rights. In this sense, what you're talking about is a combination of somebody who understands what a public-private key right system is, a pseudonym, how it can be used. Somebody who understands law and therefore can construct. something that will withstand in court. You build a system that's holding value, for example. You want to be able to defend that in court when somebody sues you.

And somebody who understands people, such that the people themselves will hold on to this value and perceive it as value, if you like. You go look at Bitcoin, for example. It's this amazing invention where you go out there with absolutely no description of what it is, but people hold it as value. You need somebody who understands

that trick. And that's what we call the rights layer. Then there's accounting which, you know, that comes in with all the double entry staff and transactions and so forth. Above that is governance. The problem being that once you've got all the value, you have to preserve it

from attack. And typically you do this by a number of techniques. If you go and look at, for example, what was that, company, Mount Cox, they didn't have any governance. Basically, one person was in control of the entire database. So consequently, when that one person got a bit confused, well, the money started disappearing.

And this happens, has been happening ever since value was invented. And it's a problem that you need to have these pots of value guarded by people who look after them. Even if you're talking about Bitcoin, for example, you take some large account, you need to worry about what happens when this person goes rogue, what happens if their laptop is hacked and the key is stolen? What happens if somebody rocks up with a gun and puts a gun to their head and says, okay, now you're going transfer all the Bitcoin to somebody else? Etc, et cetera, et cetera. All of these are governance questions. And the history for this is quite long and involved. The accounting consulting firms and the legal people know all about this. So you need that. Next, you need value. You need to understand

what value is. And that means you need to understand what money is. And unfortunately, there are very few people who understand this. The banks don't understand what money is. In essence, the central banks understand what money is, but oddly enough, they've forgotten how to issue it. So you need people who understand the economics of how this all works. And when it gets to, for example, other instruments, if you want to start trading other instruments, then you need much more knowledge again. Finally, what I call the finance layer is really the business layer. What is the business use case you're doing here? What is the product you're building? How does it react to users? Why would users download this stuff and start playing with it? And that's standard business

strategy, if you like, developing a product that is useful. I think that was seven layers. Yeah, I think those were it. So going from there to the topic that you're most known for, which is recording contracts, can you can you share how? How did you originally start to work on Ricardian contracts and what was the problem you were trying to solve? Yeah, so it goes back to that finance class where I'm sitting there learning about zero coupon bonds. And I agreed with my partner then, Gary Handel, we'd give it a go. We try and issue bonds on the net. So then I had to figure out what a bond was.

This whole question of value, which I just talked about, I can say that a database line is a bond. But is it a bond? What is a bond? So I did a, if you like, a deep dive into what bonds were. And in those days, it was actually a lot easier to understand what a bond was because we still had paper bonds. Many bonds were still being issued and they were floating around in the scene. You could go and buy a paper bond from somebody. And if you had a paper bond, you could hold it in your hand, which meant that it was really easy to understand. You just looked at it. It contained the whole thing. So I got some paper bonds and I read them. And the thing that's the thing that's, struck me, firstly, was that there was a whole bunch of parameterization in there. There was the name, there was the interest rate, there was the face value, things like that, and coupons down the bottom. That was one aspect which was really quite clear and, you know, that made me happy as a programmer because I knew I could program that up. But the other part was all of the script that was in there. Lots of lines, lots of text, lots of prose that said,

you know, on the certain day this will happen and we give you the right to do this and we have a jurisdiction of that, and it just went on and on and on. The good thing in those days was that because it was an A4 piece of paper, you could only put so much text in there, and consequently you could read it and understand it, because this was the entire sales brochure for the product. The product was its own sales brochure. So it was one page, just. One page, a bond was one page. The face, which is the part that it was written on, had the entire contract in there. Because today, I think a term sheet of a bond is like 200 pages or something. Right, right.

Once they went digital, it just exploded. But this was back in the day when it wasn't digital. It was just going digital at that time. And I was able to understand what a bond was, and the realization was it was a coupling of parameters and all this legal pros, which was, in effect, a contract. So once I understood it was a contract, I then asked myself, okay, what is a contract?

And that took me along another long journey where I figured out, okay, a contract has certain elements to it. There's somebody who offers the contract. There's somebody who accepts the contract. So we have two parties. There's some clauses, terms and conditions. It turns out that goods go one way and value goes the other way. So you have to identify those in the contract. And then there's some standard clauses like jurisdiction and so forth and so on.

And the interesting thing that came out of it, of all this was that, okay, my answer to how I issue bonds on the net is exactly the same as how do I issue a contract onto the net. And once I've issued a contract onto the net, actually, funnily enough, I've covered every other financial instrument because I know that if a bond can be issued, it's a contract. I also know that zero copen bonds as a theory allows me to construct everything else. And funnily enough, money can also be done that way. So when we started out this process, we thought, okay, bonds trading, we'll need a money system and we'll need a bond system and then we'll trade the two. But actually, no, what we needed was a single contract system with a contract for money and a contract for bonds.

And that was a huge insight, if you like. And if you like, it's a discovery that most people haven't made, that once you have understood that an issue of, of anything is literally just a contract. And then in the contract, you can describe what it is, and you have to describe what it is, then your system is about building contracts. You're issuing contracts onto the net. So that's how the recording contract came out as a conceptual device. So today we have a notion, my people listening to this podcast have a notion of smart contracts and they have this idea of a code running on a blockchain type thing. Back then, there was no blockchain.

So what did it mean to issue a contract digitally? What were the mechanics of that? Yeah, yeah. So the first thing is you had to describe the contract. And this basically meant you had to model the way that legal contracts were done. You had to write out some pros that said, I'm going to commit myself to managing this particular instrument, and I will redeem the contract.

instrument when you come up with the units. So the first thing was to actually describe it as a legal prose contract. And that was the invention that the Ricardium contract became. It was basically a document that captured all the legal pros you wanted to shove in there. It was entirely free. It had a bit of meta-code in their markup language just so you could do the parameterization, you could identify the name, etc., etc. But fundamentally, it was a contract that described what it was you're going to issue. Now, having described, it, you then have to get it out there onto the net. And this is where we now swap domain.

We have to build an accounting system which accounts for units of this contract. So literally an accounting system in this concept would simply have a thousand of them. So you go into the database and you'd say, okay, I need to magically create a thousand of these. So I transfer it from this account and that goes down and it goes into this account which goes up. So now I've got a liability over here and I've got an asset over here. This is standard double-entry bookkeeping and so forth and so on. And now that I've got these assets, or these liabilities, which are you want to look at it, I can now carve them up and send them bit by bit to various people.

So you need an accounting system that would manage those units. So you could issue 1,000, you could carve them up, send Alice 10, send Bob 20, etc., etc. And that's why accounting was such a big part of the financial cryptography in seven layers. Now, the problem is the accounting system was good at numbers, but it was terrible at concept. It didn't understand what it was moving around. As far as it was concerned, a bond or US dollar or a castle or an airplane, they were all the same thing. They're just numbers. So we needed a way to link the contract claim that you made with the accounting.

And that's where cryptography finally showed how to do it. We took the contract document and we hashed it, took the cryptographic message digest, and it's this big long string. We're using Shah 1 in the day, which is about 20 buys long. And then that became the unit that was accounted for in the accounting system. So the accounting system no longer cared what it was dealing with. All it had to do was to keep the numbers good and balanced and fair. and every time it moved a number around, it would move a number of these hashes.

So what we'd done was we'd actually elegantly sliced the world of law from the world of accounting. And we'd done it with this hash in the middle. And the fantastic thing there was that even though they were entirely sliced, the lawyers didn't need to know any accounting whatsoever. The accountants didn't need to know any law whatsoever, but they were logically coupled such that you could never get confused about what the value was. And that was the recording contract.

This notion of a document then hashed and then accounted for as a hash. Brought the whole thing together and made it end to end-to-end secure. Let's take a short break to talk about Bitfinity, the Miami blockchain conference to be held this year from October 30th until November 2nd. Blockchain technology has been exiting the world of nerds and hackers and entering the mainstream. We're at the beginning of a big revolution that's going to fundamentally change how the world works. At the Bitfinity Conference, we're going to have the heavyweight speakers, such as Don Tapscott who wrote the book The Blockchain Revolution, or Joe Lubin of the startup consensus.

But we're also going to have the industry panels that focus on real-world use cases and bring together both the tech expert, who really understand blockchain, and the kind of key decision makers that will help blockchain become a real commercial success. Now you may just want to pack your bags and buy a ticket to Miami, and that's certainly a good idea. But if you're involved in a project or startup, there's something even better. Bitfinity will feature dozens of presentations by starting startups so you can apply for the presenter package, get an exhibitor stand, and speak on the main stage to an audience of

500 to 1,000 high-level people, including many VCs and top decision makers. And of course, all that while sipping in martini in a luxury hotel in Miami Beach where Frank Sinatra once staying on stage. To learn more how you can join startups like Factum, Consensus, Everledgeer, and Stellar, visit them at bitfinity.com slash epicenter and find out how you can get 10% off the company presenter package or your $200 discount code to attend. We'd like to thank Bitfinity for their support of Epicenter. How would the accounting system work?

Because today we have blockchains, and in a way the blockchains can do this accounting. But if you don't have a shared server, or, you know, if you have this traditional client server architecture, how would you manage an accounting system? Yeah, yeah. So this is where the accounting starts to get interesting. Now, the obvious thing is what you do is client server, and you just have this button that says pay Alice. from Bob and it does all the transactions. And at the back end, there's this double-entry accounting database that moves the numbers back and forth and reflects it. The problem with that is, as David Chor was pointing out, the issuer is as much a threat as any other crook. And the issuer can, for example,

fuchs with the numbers, can make numbers up. The issuer could also reject transactions, could steal money, etc, et cetera. And these are real problems today. For example, in the stock exchange world or the financial world, the issuances of shares are frequently overissued against the policy of the owner of the shares so that people can short sell against these shares. So, for example, there have been cases where there are 200% of the shares out there trading. because the issuer, the registry, has made a little bit of money by adding extra numbers and selling them to short sellers. And this is an ongoing problem today. It's not some blip, it's not some scandal, it's literally how they do things. And then you've got things like Cyprus, where you've got the bailium problem, you think your money's in the bank, and then suddenly your money's not in the bank, because they've taken it away.

Now, that becomes a problem. We looked at that, and we knew that Chorm was trying to solve the, that, and we tried to solve it too. So what we did was we changed the request such that it was cryptographically signed. Your pseudonym would sign the request. And therefore, you had a good authorization to move the money. And then what that meant was that the issuer could no longer blithely just change the numbers and handwave. The issuer was bound by, or the issuant server was bound by the signed requests that it received. And then out of that process, the issuer would then sign a receipt, including the request, so that you never lost the information, and send the receipt back to the two parties concerned. And consequently, the accounting then became a very simple

act of collecting all the receipts and counting them up. And for most of the issue and service that I've built, it's been literally that. What we do is we have a collection of receipts, and we analyze them as new requests come in, turn them into receipts, and add them to the set. And when I want to figure out how much money Bob has got, I just collect all the receipts with Bob's name in, and then go through one by one and add them up.

There's no balance in the system. But we have to calculate a balance every time we do a transaction. So this is obviously a scaling problem. But when you're dealing with small systems, it doesn't really matter. You never notice the difference. It's like sub-millissecond. So what we'd invented was this way to control the issuance server from getting away with inventing money or moving money without permission.

Because simply put, the issuance was the sum of the receipts that were both authorized by Alice and receipt signed by the issuer. I have an issue. And it was out of this concept that we came up with this notion of triple entry, because the receipt itself was now shared between the payer, the payee, and the issuance server. You needed all three because if you only had the two of them and one of the two lost their copy, there was now a potential for abuse. And you could control that abuse by having all three, then agree on that set of triangle receipts. And it was this, if you like, in the terms that we used today, what we'd have done is we'd establish consensus over a single transaction.

And we'd establish consensus over a set of transactions using this cryptography trick. It was out of that that we came up with this notion of triple entry, which, oddly enough, was a reinvention. or not a reinvention, but it turned up in two different lines at the same time. We were building it in 95 through 97, and then I didn't really understand what I was talking about at that point. It was only later on in about 2004 or so that I had this inspiration, that it looked entirely different, because it wasn't double entry anymore. We were doing a transaction system that wasn't double entry.

What was it? Well, it turned out to be triple entry. So I wrote this paper, sent it across to Tob Boyle, who I knew was right into this stuff. And he said, oh, yeah, I invented all that ages ago. So I had a look and there it was in his website. Oh, yes, and then you organise these entries and it's triple entry. So I somehow had absorbed the term into my head and felt that I invented it.

And in fact, he'd invented the term and he'd understood the concept five years before I got anywhere near it. Personally, I would like to go into Todd Boyle because I think he was also one of the first people to come up with the idea of shared ledgers. Right. But when you were talking about Ricardian contracts, I felt that what you have kind of described with Recardian contract is a very simple design pattern that occurs in many kinds of technology.

So I'd like to give an example and, you know, get some of your feedback. So, so for example, let's let's take the shipping industry. right. Now in the shipping industry you have two major parties, the shipping and logistic industry, there are two major parties that are interplaying with each other. So I might be a big manufacturer and I want to ship something across the world. And then there's the shipping system which is moving these physical goods across these networks, across the seas, etc. And you need like a common interface between these two parties, the manufacturer and the receiver of the goods and the shipping industry. And what the shipping industry created in the 60s and it became a huge success was the container.

Yes. So the container is like an abstraction that says, okay, here's the container. The shipping industry gives the container to the manufacturer and the manner and says, hey, whatever you want to transport just fill into this stuff, right? We don't care what's inside this. What the shipping industry case is like, okay, we have the container and now we have all this technology and all of our ideas to move this around. And on the other side, the receiver can just take the things out of the container. So it's this container is like a lubricant between these two diverse groups. And what I felt when you were talking about Ricardian contracts is that you're using this hash as a lubricant between lawyers and software engineers. accountants, right? Yes.

So the lawyers, they want to write the rights, the terms, the governance concerning financial instruments. That's what they care about. They want to write it in English language, and they really don't want to change their habits. The software engineers on the other hand, they care about the accounting system. How would that happen? How would atomic transactions happen? and how do we prevent hacks inside our system? They don't really want to care about all of the rights and stuff. And you need some kind of lubricate, lubricating mechanism, because these are two very diverse groups who normally do not intersect. There are very few coder lawyers.

And what the Ricardian contract is from this perspective is this lubricating system. Here's a hash. Lawyers, you write this stuff, it hashes down, and now the software engineers can just take this, hash and build their accounting system around it. So you could almost say that the recording contract is the shipping container of the digital world, of the financial cryptography world. You could say that. And you're right in that it's become a design pattern. Originally it was just, well, it wasn't even an invention. We didn't even call it an invention or a thing. And that's why it's got such a strange name. It was the contract

in Ricardo. Ricardo was the contract in Ricardo was the... name of the system that we were trying to flog in those days. And every time we come out on this question, we always said, well, the contract that's in Ricardo. And eventually that morphed into Ricardian contract. So you could say that the design pattern of taking a human readable document and then hashing it and then passing the hash into the other system, which might be an accounting system, or it might be something different. Yeah, that's become a design pattern.

And indeed, this is just to sort of slip ahead. That's the way that you should interpret it because when you start talking about, for example, smart contracts, what's a smart contract, etc., etc. Go back before Bitcoin, what was a smart contract? Actually, it didn't exist. It was an abstract notion. It was a concept. Whereas Ricardium contracts were abstract. They existed as a design pattern, as an implementation, as a design specification.

and so forth. So if you like, smart contracts were up there in the thought space, and Ricardian contracts were down below thought space, but in implementation and abstract space. So what has happened, if you like, as they've come together, as the demand for these products has come together, the Ricardian contract has become one way in which you implement the abstract notion of a smart contract. Very interesting. Very interesting. So the question is, Why do you think Bitcoin, the system, doesn't need, does it need recording contracts? If it doesn't, why doesn't it need recording contracts and why didn't this play a role in that system? That's a great question.

And it really speaks to the understanding of what's going on here. And actually, it took me some years to figure this out myself. So the thing about the recording contract is it makes an assumption that you want to, to issue something of value like dollars or pounds or euros or shares or, you know, lollipops or whatever it is. And you're an upstanding person who wants to do the right thing and redeem these units such that when somebody comes to you with the digital unit, you'll hand back what it is that's underlying. And it could be anything. For example, there's pressed flowers, which was issued at one point. And in the contract, Sylvia Byrne said, this, I'm

I will give you press flowers if you send me back the digital things, but I have to take a bit of time because I have to then go and borrow the flower machine from my daughter. It's a contract. She's making an offer and she's putting limits in there. And the assumption was that every piece of value would always be like that. Somebody would stand behind it as an issuer and somebody would have terms and conditions and so forth. So we had to have a contract. Now, the problem that occurred with Bitcoin is that,

Satoshi Nakamoto started from a very different frame of mind. In the 90s, everybody was thinking client server, I was thinking contracts, etc. In the 2000s, we had a very different philosophy. Things had changed. Peer-to-peer had turned up, but that's an aside. What we'd seen was the failure of e-gold and the morphing of PayPal and the failure of various other places. there was another one called Liberty Dollar, and then there was Liberty Reserve.

All of these systems had failed. So when they were doing the work to build Bitcoin, Satoshi, the team, what they were doing was looking at all these failures and saying, well, why did they fail? And the reason they failed was because there was an issuer and there was a contract and there was something that could be attached. And eventually, if you had enough of these controls, what would happen is it would be attacked by somebody. And of course, we talk about the government coming to shut these things down, but it didn't have to be a government. Sometimes the system's collapsed by themselves because an insider stole the value.

Sometimes a thief came along and stole the value. So if you think about Mount Cox, if Mount Cox was an issue, that would be a classical thing where you know it's collapsed, but you don't know whether it was an insider or an outsider. The problem being that, in fact, there was an issue, there was a contract. So what Satoshi figured out was that what was needed was an instrument that had no contract and didn't have an issuer. So after a lot of thinking what they came up with was this notion whereby they just invent the number. And if you remember my accounting on the right-hand side and the law on the left-hand side, they just swept that part away and had the accounting.

And the accounting just dealt with numbers. and it said nothing about what the numbers meant. There was no contract. They didn't need a Ricardian contract. In fact, they couldn't have a Ricardian contract because as soon as they had a Ricardian contract, there was something in there describing how to attack it. So they were faced with, if you like,

it's the exception that proves the rule. And it really is the exception, because as we found out in time, once you had Bitcoin, you could only have one of them in the technological space. Because it said nothing, as soon as somebody tried to copy it, that was an inferior copy of something that was more powerful, even though it said nothing. So the network effects kicked in very strongly and all the alt coins sort of drifted away. So you had this situation where it had to be dominating by the nature of its space.

So what you then found was that people started to think about issuances and shares and so forth and they came up with this colored coins idea and so forth and so on and a lot of the reason why that didn't go anywhere was partly because Bitcoin established a notion of being, if you like, a Wild West but an unregulated place so the regulators weren't there, couldn't be there. If anybody tried to issue shares in there, it was like a red flag. And the other thing was that they weren't using recording contracts, so they couldn't describe it so the users didn't know what they were talking about. And they ended up being dominated by scams.

So, if you like, Bitcoin is the exception that proves the rule in the sense that you really do need a contract if you're issuing something. Or basically you're issuing something that can only be one, and it's the one amongst the community, which is why you get this angst from the Bitcoin. community against, say, the Ethereum people. The notion of issuing another Bitcoin or another Ethereum token or what is attacking the notion, is attacking the coin that is the one. So, yes, Bitcoin can never use the recording contract. So we have Bitcoin, right? And I think your analogy makes a lot of sense.

So the description, right, that you essentially remove the contract aspect of it. But now we also have blockchains in all kinds of other ways. We have permission blockchains. We have Ethereum. We have private blockchains, et cetera. And how do you think that the existence of blockchains and of smart contracts, how does that change the relevance of recording contracts? And do you think that there will be important ways and they will work together synergistically?

or does it mean that the recording contract was mainly a precursor and it's not as relevant anymore at this point? No, they will merge. The Ethereum people are going through a learning curve as to what it is that they're issuing. They haven't really understood how to issue an instrument as yet. And if you look at, for example, the Dow, part of the problem with the Dow was that they weren't clear on what the contract was. So when push came to shove, when it fell into a mess, they changed the contract arbitrarily. And by arbitrary, I mean, they used this process called consensus, which they kind of invented on the fly. They also labeled it democracy, et cetera, et cetera.

All of these things were basically arbitrary. They did what they could do at the time. But in effect, they hadn't nailed down what the contract of the Dow was. They hadn't written it down properly. They had written it down. It was on the website. but they then hadn't linked it into the contract that was running on the Ethereum chain. There was no, if you like, logical and tight pointer locking the two together,

the contract from the accounting on the chain. So this will happen over and over again until they get the bright idea of locking these things together so that people can actually understand what it is they're investing in and be guaranteed that that won't change arbitrarily the moment any change. trouble turns up. There's a bunch of other things they have to do as well, but that's aside from the recording contract. The other issue is with smart contracts. The demand in terms of the public perception is for smart contracts. It's not for issuance of instruments. Issuance of instruments is considered interesting, sexy, but not much fun. What people are finding fun is smart contracts.

Now, the problem that happens with smart contracts is that fundamentally people want them to be contracts. They want them to be actual agreements between people that happen and they automate themselves and they perform and so forth and so on. The problem that occurs then is that if you look at a contract, there are parts that can be automated and there are parts that cannot be automated. So, for example, if you look at the DAO, for example, it was impossible to automate the response to the hack because we didn't know what was going to happen. So there was no way they could write it. If they wouldn't do it again, if they ran another DAO, they could write in there, if we're hacked, we do this. But what happens when something else goes wrong? So there are certain parts where you have to basically say, okay, in the event of a certain circumstance, which we can,

predict, we will do X. And that X has to be written in some fashion. It can't be automated because we don't know what's going to happen. And this is typically called dispute resolution in the sense that what you do is you would say, okay, in the event of unforeseen circumstances, go to the court and get a ruling that says do something precise, having been informed by the circumstances that we're now informed with. And so consequently there's this area in contracts which just cannot be automated for very solid, real philosophical reasons, if you like, or real world circumstances. And consequently, when you build a smart contract,

what you need is both the code to do the automation and the legal pros that goes alongside it to answer what happens in those other cases. You need both. You can't really do it without it, as we found with the Dell. So consequently what happens in the future is that we take the two and we merge them together and in a sense it was always there anyway. The recording contract already had some parameterization and it was always possible, for example, to add some code into a recording contract.

It's just that we never saw the demand. Now what will happen is that we'll take the two, put them together into a single object such that the running code on your Ethereum chain will point back to the same. the legal prose as an external document so that we'll lock in the terms and conditions. And the other thing that's happened is that with a fair bit of thought, and this is another long digression, so I'll just skip past it, the notion is that we should take those parameters out and stick them into a separate block. So we end up with this tuple, this triple, which is the pros, the code, and the parameters. And then we can start doing things like finance much more

easily because we take a boilerplate contract, take the code and the pros of it, and then we just parameterize it to create the deal, to drive the deal. Wrap that up, and we've got a triple of information, which is what they're calling the Ricardian triple, because it kind of follows the line of Ricardian better than any other metaphor. So what happens in the future is that smart contracts will be implemented that way with pros, with code, with parameters, wrapped up into an object that is then unleashed onto your chain, your blockchain or your cordelike system, and run until something goes wrong or it terminates. So, yeah, to answer the question, yeah, it's entirely relevant.

It's, but it's morphing as time goes on, as demands happen. Yeah. So, I'll contribute like one example to what you said. and then one question, right? So you said that there were, there were parts of the Dow agreement that could not have been automated, right? And perhaps our listeners would appreciate

that the role of the curator, etc., could not really have been expressed as pure code. But I'll give you another example, and this really opens up a big industry. So anytime you have, a loan right so in the bank giving meher the loan Ian the P to P lender giving meher the Bower alone right and this is a massive industry right like loan like the total outstanding value of loans is much greater than the total outstanding value in

shares for example in society yes if you have a loan and you rep and you try to represent a loan as a program as a the smart contract, then the problem that smart contract is always going to have is what happens when the borrower defaults. Yes. So in the case of default, the program can only impact the entries inside the accounting ledger. Yes. But it cannot do anything outside the accounting ledger, right? Maybe influence other systems like reduce the borrower's credit rating or maybe try to go after other assets the borrower has. These are things a smart contract program can't do. So if you wanted to represent a loan as a pure program, you would fail. But then if you said,

let's represent a loan as a program, smart contract, plus a Ricardian contract, then this combination of these two things would be able to represent it. And so this combination can essentially open up like trillions of dollars in financial assets for representation in a fashion that both allows legal enforcement and also automation. Like you can sell these loan agreements very easy on these smart contract platforms. You can package them, you can securitize them, etc. And you also get the benefit of law enforcement. So yeah, in the sense that when you're dealing with issues like default,

it's practically impossible to automate that situation, especially as now very probably entering the domains of bankruptcy or courts or something like that, and they have very peculiar rules about how they play this particular game. So consequently, any attempt to code that up is fraught with the potential for making matters worse. So what you need to do is to write your smart contract such that when it detects a condition like this it goes into some sort of halt condition it goes into some sort of condition that says okay

I can do no more I have to stop here and pass it to outside and the problem with that of course is that you can't really predict it enough so you need that prose alongside to say how this is going to happen But it's interesting because once you've done this and once you've moved on to the situation with, say, many smart contracts operating in the same fabric, you can also do things like hand your dispute resolution across to a smart contract which handles dispute resolution. and that particular program, that smart contract, could handle dispute resolution much more in a refined fashion because that's all it does. And it can be updated over time.

It can update itself over time. So consequently, it's if you're like inching your way up the chimney. Once you've got the issuance of assets sitting there, even though they go into default and they have to stop, you can have other smart contracts working to assist that process. And gradually, you can get the entire financial system into the space. But that's, we're now thinking years ahead. Yeah.

One of the very interesting points at ERIS, one of our engineers, who's also a lawyer made, was that it would be quite easy to code in these things where it's like, okay, exception, now it triggers some other process, right? Like the bankruptcy process, the evaluation process, the committee looking at it. But what will be very, very hard is once that has been triggered to go back into the automation part. So it was like, that is going to be a massive challenge because you can code those things in, but then there's some super long dispute or years in court and stuff. And then in that time, it's like the smart contracts isn't functional anymore.

Yes. So this is going to be where Ethereum and blockchain style designs get into trouble. because they're incapable of easily migrating that fashion, which is one reason, if you like, why Corder, for example, goes into different direction in the sense that it only shares the contract between the parties. Now, that means you and I, the three of us, we can have a contract, we're the only parties that see it,

we can still go into default, we can still go into a state where it's stopped. But then assuming that we have written in a dispute resolution, clause and assuming that dispute resolution knows what they're talking about in terms of smart contracts, then you can have that dispute forum run a case and come up with a ruling. And that ruling is binding on the three of us because we agree to that up front. And that ruling can say, okay, now that I've figured out what you're up to and I worked out what's wrong, I therefore rule that you do these payments back and forth to correct the

bargo or whatever it was and then you restart the contract. at this point. And the three of us then have to work out what that point is, sign it, come to consensus that we've signed it, and then carry on as if nothing else had happened. But we can do that because A, it's only the three of us, and B, because we have a ruling that binds us to doing that. We have to do it. We don't get to make up our minds.

We are told we're going to do that. Otherwise, we're departing the forum, which means we're breaching contract. So you can do that in a system like quarter. You can't do that in Ethereum because you've got open access, you don't know how many civils are in there, and none of the civils agree to anything. So they're caught on the, they're trying to go for maximum flexibility, but in fact, they're highly limited in the way that they can deal with unforeseen circumstances until they add dispute resolution. Very interesting, very interesting indeed. So one final question from my side, because we are out of time for our podcast, is so for any new technology, there's the engineering side of it, and then there's the business

side of it, right? And now, as like people approaching it from the engineering programming backgrounds. I feel very comfortable that we have a technology that allows us to represent any contract we want, any kind of financial game we want to play with each other as a contract that's both legally enforceable and automatable. And I'm fully comfortable with this idea. I think we can do it, right? Given we have all of the right skill sets for it. But then there's the other business side, which is that any game-changing technology faces a lot of legal hurdles, regulatory hurdles of inertia, hurdles of education, right? People really don't want to adopt new technology.

If I really look at like, I have common people, they don't really want to adopt technology. They don't want to figure out what these private keys are. They don't want to understand how to keep them safe. And it's just hard. And I sympathize with that. like with that you know mindset and like technologies like new technologies in my opinion breakthrough into society only when they find a killer app or something that improves some aspect of life that like hundreds of millions of common people care about by a factor of 10 it's a

very high bar on the business side and my question to you would be does this this our technology of representing contracts like this, clear that bar for hundreds of millions of people in a certain way, or in other words, is there a killer app for this technology? So the obvious problem with killer apps is that if I knew what it was, I'd go out and build it and we wouldn't have time for this podcast. So there are some applications in there which do strike out as being particularly attractive For example, the reconciliation problem is something that really causes the banks a lot of grief. If you look into the bank systems, there's this cancer of differing records, disagreeing slightly.

And 99.9% of them will agree, but the 0.1% that don't agree cause a lot of human labor. and some of these things never get resolved, and they're all swept under the carpet, and you have problems with audits and so forth and so on. If you could use this technology to guarantee, by using cryptography, receipts and so forth, to guarantee that everybody's looking at the same data. If we achieve consensus over the same data,

we have a possibility of massive cost savings throughout the banking system. This is not really an advantage to the rest of the world, because outside, we tend to... to resolve our problems just by picking up the phone and talking to people and saying, oh yeah, well, these are the numbers and we just change the numbers. We're fine. But when it comes to corporations communicating with each other at scale, there's a massive problem when the numbers don't match up. And that, if you like, this is why the triple entry thing is quite interesting.

What it does is it takes the magic of double entry, which is that it makes the accounts reliable inside the firm. And that allowed the building of the great trading houses in Italy, in the, you know, back in the 13-400s. That allowed the eruption of the firm because it could now manage its accounts. And it's like a truism that if you don't manage your accounts, your firm will get to 25 people and file. You go bankrupt because you don't know where your money is. Double entry enabled that to happen to go beyond that barrier. Triple entry now does the same thing between the firms. So we can now, if you like, even reverse the process, if you're familiar with COSA's transaction costs theory. The size of the firm is shown by the costs of internal transactions.

If the internal transactions become very costly, then the firm gets very large. If costs become large in transactions. So what happens now is if you can do cheap transactions between firms, without having the reconciliation problem, you can start to reduce the size of firms. You expect to see a reduction in the firms. So that's actually a very important thing, reconciliation, and replacing it with cryptography. But the path to making that happen is very long and tortured

because it's not about me downloading a tool and starting to use it. We've all got to download the same tool at the same time and start using it for all our transactions. Right. So it needs that magic entry. So therefore, it's not a killer app in and of itself. And this is why Trimple Entry, for example, never really took off. It's taking off on the backs of other things without being known.

The other thing, the work I was doing in Kenya, which involved taking the accounting for social savings and placing that on the phone as issuances of value. That, in my view, was a killer app. Unfortunately, we were just way too far ahead of our time, and it's now sort of like a truism that you can go there and use blockchain to solve all their problems. You can't. You can use financial cryptography to do it, but blockchain isn't really attacking what their problems are.

But it's certainly the case that if you can replace all of their accounting with shared accounting on phones, then you can make a huge difference to their lives. And this is a difference which goes across all of Africa, most of Asia, pretty much all of Latin America, and so forth and so on. So that's pretty huge. And that'll happen at some point. Cool. Well, thanks so much for sharing that. It would be fascinating to see when that happens and how it happens and in the war corner it happens.

And then maybe we'll also see lots of things that are unexpected with all the different problems people are working at. So, yeah, we're at the end of our episode. actually ran pretty late, but I think it was a super interesting conversation, so that's not a problem at all. So thanks so much for joining us, Ian. Great. Good to be here. And thanks to our listeners, of course, for once again tuning in. Of course, we're going to have links to a whole range of Ian's papers and Ian's blog on in show notes, financial cryptography.com. And so you can read up those, it's highly interesting. So Epistenter is part of the Let's Talk Bitcoin network.

You can find this show and other shows on Let's TalkBitcoin.com. And of course, you can subscribe to the podcast on any app or watch the videos on YouTube.com slash Episenter Bitcoin. Thanks so much and we look forward to being back next week.