151 – Ian Grigg: Ricardian Contracts And Digital Assets Prehistory

Transcript

This episode of Epicenter is brought to you by Jaxx. Jaxx is a user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to 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 in a wide range of industries. Go to bitfinity.com/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 Crain. 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 his 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 Ricardian contracts, what they can be used for, and the future of the merger between smart contracts and Ricardian contracts, and technology such as smart legal

agreements. So, before we start, let's have a short introduction from Ian about his background. Ian, could you could you tell us a bit about your background and how you got interested in crypto in merging cryptography with finance? Sure. Um so, I I was a uh systems programmer by trade uh way back when. And in 1995, I I was sitting in finance classes. I was doing an MBA uh 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 uh Amsterdam, uh an old programming mate of mine, Gary Howland, 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 uh Netscape had just gone through its IPO in in '94. Uh 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, you know, very exciting at the time. It was a huge hype uh bubble. And Gary was feeding me all this information from from DigiCash about how it was was working, what the technology was, you know, read the articles and so forth. And I I sitting in finance classes looking at zero coupon bonds, and I realized the zero coupon bond was exactly what they'd invented in Amsterdam. Uh and the 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 uh equity, bonds, derivatives, and so forth. All of these, all of finance, could be implemented using this technology. So, that's uh so, basically talking to Gary, we decided to give it a go to put all of finance onto um onto a ledger arrangement. Uh, I don't want to use the word distributed ledger yet.

Uh, so that's how I got interested uh in finance classes um we brought the together those two and then moved into uh 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. Uh, there was no peer-to-peer. Peer-to-peer hadn't been invented until uh there was another five years coming, 1999. Um, so what DigiCash were about, uh David Chaum was a privacy advocate. He spent a lot of time in uh as a cryptographer, a real cryptographer, doing real cryptography to preserve privacy. And

his notion of money was based on the uh the metaphor of the digital coin or the hand-to-hand note. And this has the property that uh when you and I change uh a note over for some you know, a drink or uh 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 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 uh a world of mass surveillance and mass control and all of all worlds' uh nightmare scenarios in his books would come true. Uh, 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 uh when I get it, I run this special blinding formula, uh, 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, uh, the issuer to sign a coin, but that signature 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 me or uh, without having to, you know, ping DigiCash server to change or register something. You can do that directly, and then Mayur has it.

Yes. And in the process of handing it over, we will refresh it. don't have the double spend problem. Uh, 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, uh, in the Bitcoin world. It came from prior, uh, 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 a bit like Zcash to to me. Because in in Zcash, you have these public coins, and then you can go go through a process, and like you can have create these private coins, and then once you send these private coins, uh, 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 uh 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'd 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 uh the the situation. And that was kind of necessary in a formal banking world in the sense that uh if you were 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 the fact that you wouldn't actually allow it to happen. So, what was the advantage of a design like that versus just Digicash having um essentially like uh 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 Maker's coins. Why would you do it with this coin format that requires this refreshing? Mm. Yes. Um so the the arrangement with Bitcoin, which of course is like the is 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 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 to obfuscate the trail. Um why wouldn't you do that? Uh the 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. Uh in practice, there were two things that went wrong with with eCash. Uh the first of which was that everything was trenched 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. Uh and secondly, the clients weren't really set up or you know, people weren't really set up to hold the coins uh on their own wallet because of the sensitivity with backups and so forth.

So, you you had this tendency whereby people would just use the account at the bank or the mint. Uh and when they needed to do a purchase, they'd 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 really you needed sophisticated clients to pull this trick off, and you needed a lot of traffic before it started to actually develop its suit 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 and what happened? So, it's a little bit difficult and and this is unprovable, of course. The people who are involved have uh have basically, you know, denied knowledge of any of this. The 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 in scientific papers and and uh Cypherpunk rooms for quite some time. But it was the first time anybody could do it. So, people started downloading the stuff. The open media caught it and started writing articles about this. I think there was a Wall Street article or something like that. Then, the central central bank picked up on the article, De Nederlandsche Bank, which is in Amsterdam, of course, picked up the phone and called David Chaum and said, "My office, Tuesday, 9:00." Bang.

And in that meeting, which was, shall we say, uh not a happy meeting, the compromise that came out of that, uh the Nederlandsche 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 um DigiCash agreed to only ever sell to commercial regulated banks. And consequently, if the banks didn't need or want the product, they were they were back in control.

So, what happened was a 5-year period where uh DigiCash went around and sold to banks. But if the product wasn't fantastically successful or if there were roll-out problems or they realized that actually this had unfortunate circumstances, uh 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 a project called um SET, I think it was.

Secure electronic transactions or something. And that was, if you like, a 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 DigiCash. We'll just do SET." Which of course was internal controlled and not adventurous. And that kept going and it just sucked it sucked the energy out of the field.

Uh so, DigiCash was never able to sell into a if you like an unbiased party that really wanted to make it happen. And what about other projects was there besides DigiCash? I mean, you said you were in involved in a in a startup then and maybe there were others or was it really DigiCash this dominant player? It was dominant because it had the patent uh for the cryptography. And it was it for a few years that enough alternative cryptography surfaced that allowed you to bypass Digicash's payments, which is what I did later on.

Um when I started, you know, May of 1995, Gary and I agreed to do this. I went to Amsterdam and for 2 weeks all I did was market research. And I discovered 20 companies already doing something similar. At that point, after 2 weeks, I said, you know, enough is enough. I know what they're doing. And I and I stopped. And from then on, for the next 5, 6 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 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 make to get to the end, uh made me realize there are a lot of, if you like, polymath disciplines involved in trying to make it all happen. And um there was actually a layering in terms of the way these intersected together.

And out of that came that paper, FC in in seven layers, which when you've read it again, it feels a bit obvious. But um actually, the big message that comes out of that is that really it is too much for one mind to conquer because your specialty uh 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 Jaxx. Jaxx is a multi-coin wallet created by by people at Decentral. Now, in the past, if you had a whole bunch of cryptocurrencies, it was a pain to handle them. You either had to leave

them on an exchange, which is insecure, or you had to have all these different wallets, which was a hassle. Fortunately, now with Jaxx, those medieval days of darkness, misery, and suffering are over. Jaxx supports multiple cryptocurrencies, and new ones are being added. But, it's not just storing cryptocurrencies you can do with Jaxx, but you can also change them directly from within side the wallet, thanks to their ShapeShift integration. And since there's only one seed, Jaxx makes it super easy to back up and sync to your other devices. Jaxx works with Windows macOS Linux Android iOS and has browser extensions for Firefox and Chrome. So, go to jaxx.io, that's

jaxx.io, to download the wallet and get started today. We'd like to thank Jaxx for their 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 DigiCash, I've actually read in various places a different account of the failure of DigiCash, and uh I'd like your opinion on this account. So, the account I've read is that like DigiCash essentially failed because um it failed to anticipate that credit cards could also be moved to the

internet. So, when 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 any amount out of your credit card. So, you needed a way by which credit cards could come onto to 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 in plug 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 of this? Yeah. So so as technologists, we seek an answer in the technology. Uh clearly the credit card won, so it's better technology for the for the game. Uh and Digicash had flaws. Um but actually both had flaws. If you go through and list out the flaws, they're both equally flawed in in various respects as as you pointed out.

Now, um my opinion is that it was nothing to do with the technology. It was purely an institutional question. The credit card companies and the companies surrounding the credit card companies had the institutional mass to make it work. And key amongst them was the uh the Netscape and RSA DSI partnership which uh started out by uh started at '94. They were already on the road at this stage before before Digicash started building up.

Um with this little thing called SSL to try and protect the uh the merchants' credit or the credit cards from being snaffled uh over the net. And that was uh a very large and institutional play that um morphed into the whole VeriSign thing, which became a very rich company uh 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 SHTML. Uh we we ended up with HTTP S uh or was it yeah SHTTP 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 Chaum and a patent. So you're saying that SSL also was invented specifically to solve this issue of 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 like explaining this uh it's like if if say I'm the merchant and Ian is uh the buyer and uh 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 it 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? Ha. Lots of them. So for example uh one of the things that is very typical is that companies build up their mechanism they they 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 Mary 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 the notion that you can do two things at once and guarantee that either both happen or neither happens roll back or roll forward. But typically what happened was that the the financial cryptography companies would come out there and install a database which they you know put together my sequel 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 up. And you see this for example in the DAO. Um this is precisely what happened. The transaction that's in there or the the 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 you you're always going to have a problem. And um consequently what happens with the smarter companies the ones that get a bit further down the 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'm I'm I want to ask another question on that. So that's that's a technical one. Yeah, you're certainly right where we've seen that in the Dow. I I guess with Mount Gox maybe there was some of that too with the some of Same thing. Same thing. Yeah.

But what about the business side? Do you also see cuz one of the big issues that Meher and I talked for example last podcast was that it seems to be that companies struggle a lot to find a business models that work and and a user base that works. Yes. see what are your takeaways on that point from from from back then and what happened back then? And and how do those apply today? Uh it's 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. Um it it comes from their own particular inspiration. And sometimes you can get lucky. Uh 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 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 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, uh back in back in the day in '95, there was a big company that got a lot of money uh doing essentially Digicash stuff.

The VCs went in and said, "You know what? This Digicash stuff is crap. It's not going to work. Uh 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 uh 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'd 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, turned 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 were now doing credit card facilitation. And that's a 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. Uh this is the startup process, of course.

Uh you can't 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 uh what's what's the country we're talking about or what's the group of users they're talking about? So, it's it's there's no generalism here. Uh finding a business product is as hard as finding a a cryptographic invention. And it's But do you feel like there is a big area or a big direction or a kind of type of class of problem that will open a lot of opportunities for maybe a company to become really big or a whole bunch of companies to to become successful and thrive? Because the way the way it looks like at the moment from

from my perspective, so there is the kind of Bitcoin case, right? Bitcoin became has become somewhat successful. Um 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 it's very hard to see. Yeah. Yeah. Um you know, to And this is where I kind of drift into R3 thinking. Um the if if you've got a context of uh regulated financial institutions and regulated

companies doing regulated business, then you can see a way forward, but it isn't blockchain. It's uh moving packets back and forth to establish consensus over a shared set of facts. And uh that's basically what Corda is designed to do. So, uh that that is a different approach, and it's an approach where you can see, for example, we start uh back in, you know, 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. Um so, the So, that if you've established that context, then that's a good direction. But, what context are we talking about? So, for example, if you look at Bitcoin, um it's popular amongst the disparate bunch of people, but all for different reasons. So, if you talk about um 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. Um and it has other flaws as well. Uh then, you can talk about, for example, remittances. Uh now, remittances work between small uh poor people who send very low value amounts from country to country. Uh now, that could be very successful, but the problem there is the remittances is a regulated market. So, consequently, you get so far before the regulator turns up with a baseball bat and clubs you. Um so, consequently, um it's it's hard to say where the killer app is. Of course, if, you know, if I knew, I would be out there building it.

Cool. Cool. Yeah, definitely. If if if if you knew, you would be building it. Today's magic word is Ricardo. That's R I C A R V O. Head over to letstalkbitcoin.com to sign in, enter the magic word, and claim your part of the listener reward. Now, we'd like to change focus, um to the notion of financial cryptography, right? Um So, I think like you run a blog, which is called financial cryptography. You have this paper, which is like financial cryptography in seven layers. You have this article, I don't know the the

source, but where you say that Bitcoin has managed to unite the financial cryptography community behind a single code base. But behind be before discussing all of this, I would like to have kind of your definition of financial cryptography, what it is, and uh what keeps it going as a field. Yeah, so um financial cryptography was a term uh invented by Robert Hettinger. Uh he was a Cypherpunk from uh way back looking at the the potential for Digicash as e-cash and various uh the many other interesting cryptographic ideas in the Cypherpunk field.

Um the observation was that um 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. Uh now, that's in opposition, for example, to cryptography applied to national security or cryptography applied to privacy. So, if your if your chat program is private, for example, that's 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 like the

core starting point. Um and uh 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 we were still in the formative uh 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 which was the you know, the topic of my work. Um 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.

Um 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. Uh and then there's a notion of rights, which is a very complicated and uh not particularly well-understood field. We see people talking about it a lot. Uh but it was really only developed to an extent by one particular school, which is the capability school.

And it it's information that the the concepts didn't really flow into the rest of the the field. Uh 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 the the two fields. You know, Zuko, for example, is one. Um who 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 um well, basically, a mess. Uh and that's

what happened with a lot of systems. So, for example, there was this system called Eagle, which I had a fair bit to do with, not my company, but not my code. Um the guy who put it together was very very smart. He taught himself to program. He was a a radiation oncologist. He was a doctor, you know, he wasn't actually a programmer at all. Taught himself to program and he wrote the whole thing in uh 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 really took them ages to get through to to clean up. And I'm not even sure they ever got through and cleaned it up. So, you have this this difficulty of trying to get all these disciplines together.

Uh and 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 and what are these seven disciplines? Like, what are these seven layers? What are these seven people? Seven skill sets? So, you've got your cryptographer. Okay. 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 that where most people understand. Okay, you need some programmers. But you also need um somebody who understands rights. Uh in this sense, what you're talking about is a combination of uh somebody who understands what a public private key right system is, pseudonym, how it can be used, somebody 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. Um uh and and somebody who understands people such that the people themselves will hold on to this value and perceive it as value, if you like. That you you know, look at um Bitcoin, for example. It's 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.

Um and that's that's what we call the rights layer. Then there's accounting, which, you know, that comes in in with all the double entry stuff and transactions and so forth. Uh 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 uh for example, uh what was that company, Mount Gox? They didn't have any governance. Basically, one person was in control of the entire database. So, consequently, um 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 it's a problem that uh 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 uh 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 to transfer all the Bitcoin to somebody else." Etcetera, etc. All of these are governance questions and the history for this is quite long and involved. You know, the the accounting

consulting firms and the legal people know all about this. So, you need that. Uh next, uh 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. Um in in in essence, the central banks understand what money is, but oddly enough, they've forgotten how to issue it. Uh so, you need uh people who understand the economics of how this all works. Uh and 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, uh 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 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 to the topic that you're most known for, which is Ricardian contracts. Can you Can you share 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 um that finance class where I'm sitting there learning about zero coupon bonds and I agreed with my partner then Gary Hanlon Halen we'd give it a go. We'd try and issue bonds on the net. So then I had to figure out what a bond was and this whole question of value which I just talked about. I 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 in the scene. You could go and buy a paper bond from somebody. Now 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 struck me firstly was that there was a whole bunch of parameterization in there. There was 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. Uh lots of uh lines uh lots of text lots of prose that said, you know, on on the certain day this will happen and uh we give you the right to do this and we have a jurisdiction of that and it just went on and on and on. Uh 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 uh this was the entire sales uh brochure for the product. The product was its own sales brochure.

So it was a one one page just One page. A bond was one page. The The face, which is the part that it was written on, had the entire contract in there. Cuz 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 prose, 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. Um there's some clauses, terms and conditions. Uh 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 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 coupon 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 um it if you like it's a a discovery that most people haven't made, that once you have understood that an issuance 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 Ricardian 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 cave you know, code running on a blockchain type thing. Yeah. Um back then there was no blockchain. So what what did it mean to issue a contract digitally? How how what are the mechanics of that?

Yeah. Yeah. So um the first thing is you had to describe the contract. And uh this basically meant you had to model the way that legal contracts were done. You had to write out some prose that said, you know, I'm going to commit myself to managing this particular instrument, and I will uh redeem the 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 Ricardian contract became. It was basically a document that captured all the legal prose you wanted to shove in there, and it was entirely free. It had a bit of meta uh meta code in the you know, 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 were 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, you know, a thousand of them. So, you go into the database and you'd say, "Okay, uh I need to magically create a thousand of these. So, I transfer 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." And 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 where you would 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 a thousand. You could carve them up, send Alice 10, send Bob 20, etc., etc. And that that's why accounting was such a big part of the financial cryptography as 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 a US dollar or um you know, a castle or uh an airplane, they're 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 SHA-1 in the day, uh which is about 20 bytes 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 Ricardian contract. This notion of a document then hashed and then accounted for as a hash uh brought the whole thing together and made it end-to-end secure. Let's take a short break to talk about BitFin IT, 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 BitFin IT 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 side of 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. BitFin IT will feature dozens of presentations by exciting 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 a martini in a luxury hotel in Miami Beach where Frank Sinatra

once sang on stage. To learn more how you can join startups like Factom, Consensus, Everledger, and Stellar, visit them at bitfin.it/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? Like cuz today we have blockchains and in a way the blockchains can do this accounting, but if you don't have um a shared server or you know if if you have this traditional client server architecture, how would you manage an accounting system?

Yeah. Yeah. So so this is where the accounting starts to get interesting. Um Now, the obvious thing is what you do is client server and you just have this um this little 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 Chaum was pointing out, the issuer is as much a threat as any other crook. And the issuer can, for example, with the numbers, uh can make numbers up. The issuer could also reject transactions, could steal money, etc. etc. And the these are real problems today.

Uh for example, in the in the stock exchange world or the the financial world, uh the issuances of shares are frequently over issued against the uh against the um policy of the owner of the shares so that people can short sell against these shares. So for example, there've 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 it's not some blip, it's not some scandal, it's it's literally how they do things.

Uh and then you've got things like um uh Cyprus where you've got the bail-in 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 Chaum was trying to solve that and we tried to solve it, too. So, what we did was we changed the request such that it was cryptographically signed. Your 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 blindly just change the numbers and hand wave.

The issuer was bound by or the issuance 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 uh the issuance 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 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 millisecond. Um so, what we'd invented was this way to control the issuance server from getting away with inventing money or um moving money without permission because simply put, the the issuance was the sum of the receipts that were both

authorized by Alice and receipts signed by the issuer, by am issuer. 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 issuing 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 situation a potential for abuse. And you could control that abuse by having all three. Then it three on that set of triangle receipts.

And it was this if you like in the terms that we use today, what we'd done is we'd establish consensus over a single transaction. We 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 it turned up in two different lines at the same time. We were building it in 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 cuz 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 Todd 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, you know. Oh, yes. And then you organize these entries and it's triple entry. So, I somehow had absorbed the term into my head and felt that I'd invented it. But in fact, he'd invented the term and he he'd understood the concept 5 years before I

got anywhere near it. Firstly, I would like to go into like Todd Boyle because I think he was also one of the first people to come up with the idea of shared ledgers, right? But I um But when you were talking about Ricardian contracts, I I I felt that what you have kind of described with Ricardian contract is a very simple design pattern that occurs in many kinds of technology. So uh and I'd like to give an example and you know, get get some of your feedback.

So So for example, let's let's finish let's take the shipping industry, right? Now in the shipping industry, you have two major parties. The shipping and logistic industry, they have two major parties that are uh that are 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 which is moving these physical goods across across these networks, across the seas, etc.

And you need like a common interface between these two parties, right? The manufacturer and the receiver of the goods and the shipping industry. Yeah. And what the shipping industry created in the '60s and it became a huge success was the container. Mhm 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 in into this stuff, right? We don't care what's inside this.'

What the shipping industry cares is like, "Okay, we have the container and now we have all this technology and all of our ideas to move this around, right?" And on the other side, the receiver can just take these things out of the container. So it's the 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 engineer / accountant, right? Yes.

So, the lawyers, uh, they want to write the rights, the terms, the governance concerning financial instruments. That's what they care about. They wanted to write it in English language, and they really don't want to change their habits. The software engineers on the other hand they they care about the accounting system. How how how would that happen? How would atomic transactions happen? How do we 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 lubricant lubricate lubricating mechanism because these are two very diverse groups who normally do not intersect. There are very few coder lawyers.

And what what the Ricardian contract is from this perspective is this lubricating system, right? Here's a hash. Lawyers, you write the stuff, it hashes down, and now the software can just take this hash and build their accounting system around it. So, you could almost say that the Ricardian contract is the shipping container of the digital world of the financial cryptography world. You could say that. Um And 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. Um it was the contract in Ricardo. Ricardo was the name of the

system that we were trying to flog in those days. And every time we came up on this question, we always said, "Well, the contract that's in Ricardo." And eventually, that morphed into Ricardian contract. Um 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. Um Um and indeed this is uh just to sort of slip slip ahead.

That's the way that you should interpret it because um 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 Ricardian contracts weren't abstract. They they existed as a design pattern, as an implementation, as a design specification, so forth. So, if you like, smart contracts were up there in the um 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 of why why do you think Bitcoin the system uh doesn't need Does it need Ricardian contracts? If it doesn't why doesn't it need Ricardian contracts? And why didn't this play a role in that system? That's a great question. Um and it really, you know, speaks to the understanding of what's going on here.

And actually it took me some years to figure this out myself. Um so the thing about the Ricardian contract is it makes an assumption that you want to issue something of value like dollars or pounds or euros or shares or, you know um 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 can be anything. For example, there's um pressed flowers which was issued at one point. And in the contract, uh Sylvie Bern said, uh "This I I will give you press files 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, you know, 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 uh Satoshi Nakamoto started from a very different frame of mind.

In the In the '90s, everybody was thinking client server, I was thinking contracts, etc. In the mid In the 2000s, we had a very different philosophy. Things had changed. Peer-to-peer had turned up, but that's that's an aside. What we'd seen was the failure of e-gold and the morphing of PayPal and uh the failure of various other places. Uh there was another one called um 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 uh 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 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 systems collapsed by themselves because an insider stole the value. Sometimes, a thief came along and stole the value.

So, if you think about, you know, Mount Gox, if Mount Gox was an issue, that would be a classical thing where you you know it you know it's collapsed. But you don't know whether it was an inside 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 the right-hand side and the lower 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 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 old coins sort of drifted away. So you have this situation where it had to be dominating by the nature of its its space. So what you then found was that um 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 Ricardian 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 um if you like, it's it's Bitcoin is the exception that proves the rule in the sense that um you 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. Um

the the notion of issuing another Bitcoin or another Ethereum cur- token or what is attacking the notion is attacking the coin that is the one. So, yes, Bitcoin can never use the Ricardian contract. So, we have Bitcoin, right? And and I think your your analogy makes a lot of sense, so your description, right? That you essentially removed the the contract aspect of it. Yeah. But now we also have blockchains in all kinds of other ways. We have permission blockchains, we have Ethereum, we have um private blockchains, etc.

And and how do you think that the existence of blockchains and of smart contracts, how does that change the relevance of Ricardian contracts? And do you think that there will be important ways and they will work together synergistically, or does it mean that the Ricardian contract was mainly a precursor and it's not as relevant anymore at this point? No, that they will they will merge. Um the 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 DAO, part of the problem with the DAO was that they weren't clear on what the contract was. Uh 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 uh consensus, which they kind of invented on the fly. Um they also labeled it democracy, etc. etc. 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 DAO 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 um this will happen over and over again uh 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 trouble turns up. There's There's a bunch of other things they have to do as well, but um that's aside from the recording contract.

Uh the other issue is is with smart contracts. The the demand uh in terms of the public perception is for smart contracts. It's not for issuance of instruments. Uh issuance of instruments is considered ah 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, um if you look at the DAO, for example, it was impossible to automate the um 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 were to 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't 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 the circumstances that we're now informed with."

Uh 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 uh 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 prose 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 DAO. Um so, consequently, what happens in the future is that we take the two and we merge them together. Uh and in a sense, it was always there anyway. The Ricardian contract already

had some parameterization, and it was always possible, for example, to add some code into a Ricardian 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 legal pros 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 also 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 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 um what they're calling the Ricardian triple because it kind of follows the line of Ricardian better than any other metaphor. Um 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 corda like

system and run until something goes wrong or it terminates. Mhm. So yeah it to answer the question yeah it's entirely relevant. It's but it's morphing as it's as as time goes on as demands happen. Yeah. So um I'll I'll I'll contribute like one example to what you said and then uh one question right? So uh so you said that there were there were parts of the DAO agreement that could not have been automated right? And perhaps our 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 another example and this really opens up a big industry. So anytime you have a loan, right? So, Ian the bank giving Meher the loan, Ian the P2P lender giving Meher the P2P borrower a loan, 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 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 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 in as a pure program, you would fail. But then, if you 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 security

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 it's practically impossible to um to automate that situation, uh especially as you're 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. Uh so, consequently, any attempt to code that up is fraught with uh the potential for making matters worse.

Yeah. 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. Uh so, you need that pros alongside to say how this is going to happen. Um it But it's interesting because once you've done this, and once you've moved on to uh the situation with um 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 uh program, that that smart contract, could handle dispute resolution much more refined in a refined fashion because that's all it does. Then it can be updated over time. It can update itself over time. So, consequently, um it's it's it's if you 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 asset or 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. Um one think very interesting points at at R 3, one of our engineers who's also a lawyer made was that it would be quite easy to 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 cuz you're going to you can code those things in, but then there's some some super long dispute or years in court and stuff and then in

that time it's like this the smart contract system isn't functional anymore. Yes, so this is this is going to be where Ethereum and blockchain style designs get into trouble. Because they're incapable of easily migrating that fashion. Uh which is one reason, if you like, why Corda, for example, goes in a 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 where 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 agreed 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 the bug or whatever it was and then you restart the contract at this point."

Mhm. 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 Corda.

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 have agreed to anything. So, they are caught on the They're trying to go for maximum flexibility, but in fact, they are highly limited in the way that they can deal with unforeseen circumstances until they add dispute resolution. Like, very interesting. Very interesting indeed. Um So, one one final question from my side cuz we are out of time on our podcast is um So, for any new technology, there's there's the engineering side of it, and then there's the business side of it, right? Like, and now um as like kind of people approaching it

from the engineering programming backgrounds, I feel very comfortable that we have a technology that allows us to represent any any contract we want, any kind of financial game we want to play with each other as as a contract that's both legally enforceable and automatable, right? I'm 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 any game-changing technology faces a lot of legal hurdles, regulatory hurdles, hurdles of inertia, hurdles of education right?

Yes. 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 break through into society only when uh 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 does this does 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. Um the so there are some applications in there which do strike out as being particularly attractive.

Uh 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 uh labor. And some of these things never get resolved, and they're all swept under the carpet, and uh 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, uh we have uh a possibility of massive cost savings throughout the banking system. Um this is not really an advantage to the rest of the world because outside, we tend to resolve our problems just by picking up the phone and and talking to people and saying, "Oh, yeah, well, these 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 uh if you like, this is why the the

triple entry thing is quite interesting. What it does is it takes the magic of double entry, which was 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 uh you know, the back in the 1300s and 1400s. 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 fail. You'll You'll go bankrupt cuz 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, it can now, if you like, uh even reverse the process, if if you're familiar with Coase's transaction costs theory. Uh the the size of the firm is is uh shown by the costs of internal transactions. If the internal transactions become very costly, then the firm gets very large. Well, if the 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.

Or you You you expect to see a reduction in the third. So that 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. So it needs that magic entry. So therefore it's not a killer app in and of itself. And this is why M-Pesa for example never really took off or it's taking off on the backs of other things without being without being known.

The other thing the work I was doing with 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 it's now sort of like a truism that you can go there and use blockchain to solve all their problems. Well 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 this is a difference which goes across all of Africa, most of Asia, most 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 that happens and in what corner it happens and then maybe we'll also see lots of things that are unexpected now with all the different problems people are working at.

So yeah we're at the end of our episode. We actually ran pretty late but I think it was a super interesting conversation so that that's not a problem at all. So thanks so much for joining us Ian. Right. 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 to a whole range of Ian's papers and Ian's blog on in show notes. financial cryptography.com And I think you can read up on those it's it's highly interesting.

So Epicenter is part of the Let's Talk Bitcoin Network. You can find this show and other shows on letstalkbitcoin.com and of course you can subscribe to the the podcast on any any app or watch the videos on youtube.com/epicenterbitcoin. Thanks so much and we look forward to being back next week.