Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Gideon Greenspan: MultiBit – The Blockchain is a New Database Paradigm

Episode Date: November 30, 2015

Gideon Greenspan, a computer scientist and CEO/Founder of the Israeli startup Coin Sciences, joined us for a discussion of their private blockchain platform MultiChain. Besides diving into the popular question of what’s the point of a private blockchain, we covered his earlier colored coins implementation as well as his view that blockchains are best understood as a novel database paradigm. Topics covered in this episode: How Gideon got involved in the blockchain space Their colored coins implementation MultiSpark and why it failed to get traction Why he saw a market for an open-source private blockchain platform and started MultiChain What mining diversity is and how it is used for consensus in MultiChain How permissions work in MultiChain The issues of privacy in blockchains and why you can’t have auditability and privacy How private blockchains differ from regular distributed databases The five criteria to decide if a project needs a blockchain The problem he sees with smart contract blockchains Episode links: Multichain website Multichain Whitepaper Colored coin protocol CoinSpark Avoiding the pointless blockchain project Private blockchains are more than 'just' shared databases Smart contracts: The good, the bad and the lazy This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/107

This is Epicenter Bitcoin, episode 107 with guest Gideon Greenspan. This episode of Epicenter Bitcoin is brought you by Voltauro, the gold to Bitcoin exchange. Trade gold to Bitcoin instantly and securely, starting at just one milligram. Go to Voltoro.com to deposit some Bitcoin and start trading today. And by Ledger, makers of the Ledger unplugged NFC hardware wallet. Half peace of mind and knowing your private keys are protected by industry standard physical security. Go to ledgerWallet.com to learn more and use the offer code Epicenter, to get 10% off your first order.

And by Hyde.me, protect yourself against hackers and safeguard your identity online with a first class VPN. Go to hide.combe slash Epicenter and sign up for a free count today. Hi, welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kutu. And my name is Brian Fabian Crane.

We're here today with Gideon Greenspan. And I had recently had a pleasure of actually meeting Gideon in person when we were sort of heiress in Israel for a few weeks. And we organized dinner. And Gideon was one of the people I wanted to meet. He's the CEO and founder of Coin Sciences. And they are behind a project called Multi-Chane, which is sort of permission blockchain paradigm design. He's also a computer scientist. So, yeah, Gideon, thanks so much for joining us.

Thank you very much for having me. So to get started, like how did you get involved in this whole wonderful industry? So there's a couple of things. First of all, I think like many geeks or technologists, Bitcoin is just very fascinating technologically, and so I've been following it for quite a few years. And then I've got a couple of online businesses that I run from previous projects I've done and was attracted to the idea of taking money over the internet without using an intermediary. In other words, without being dependent on PayPal or on credit cards.

And Bitcoin is obviously a technology that enables that. So that's kind of all got me started, trying to build some kind of business or technology around it myself. And so how did that evolve over time? So you were interested in Bitcoin to accept payment. Did you actually start doing that? You actually implemented it in your businesses? Well, no. I was waiting and waiting for the first customer to email us to ask to pay in Bitcoin, and it didn't happen.

So we didn't do that. But the problem from my perspective as a business owner was that Bitcoin is a very difficult currency to deal with in a conventional business. It's difficult to report in terms of tax, it's difficult to account for, there's some legal uncertainty regarding it. So what I was interested in developing and what got me started is a way to use Bitcoin, the protocol, to move other types of assets around. And so the first thing we did as a company was develop a protocol called CoinSpark, which is a color coin protocol. Several other protocols have been developed in parallel and since, and there's now actually six protocols that enable Bitcoin

transactions to move other assets around. But we designed one at the time because there wasn't much out there. We designed one that we thought should work kind of in the right way for the consumer. And why did you think that this was particularly interesting as opposed to just sending money around? So the idea we had was that if you could get some reputable institution to issue dollar-based tokens, for example, and have them transacted over the Bitcoin blockchain, then it could effectively move dollars or euros or pounds over the internet without an intermediary. So you'd have a digital equivalent to physical cash. And that, to us, as somebody who sells online, is very attractive

for exactly the same reason that people that run traditional stores like to accept payments in cash rather than through credit card. Okay. And so then you started Multi-Spark, and that was, was that after open assets, for example? So CoinSpark was actually, was developed kind of a similar kind of time to open assets. So funnily enough, the white paper I wrote online about how it should work, Flavian actually made some comments on it. But he was already developing something himself in parallel.

So of all the protocols that are out there, it's most similar to open assets in terms of kind of the technicalities of how it works. But it is a different protocol. And part of the thinking of the whole process was that at the time we started the company, something came out in Bitcoin 0.9 called Operatin, which was kind of an official mechanism for adding extra information to Bitcoin transactions. And to my mind, apart from the idea of moving other assets around, that was like, well, look, Bitcoin is now kind of officially a platform on which other applications could be built.

And so CoinSpark was designed not just to move other assets around, but kind of to be a general purpose protocol for using operatives to enhance Bitcoin transactions in various ways. We developed another feature as well after the colored coins one, which was a kind of messaging protocol on top of Bitcoin. So what happened with Multispark? Was there attraction with people building things on top of it? Did you want to build a business around Multisprark? Sorry, just at CoinSpark, not Multispring.

Coin spike. Yeah. Coins spike, yeah. So we released the products and I think we did a fairly good job of it and we built a whole bunch of libraries and tool sets around it. And then we started talking to people that we thought would be interested in this kind of tool. We tried to focus more on kind of more serious companies rather than kind of crypto projects

and that kind of thing. And we kind of quickly learned that from their perspective this wasn't of interest to them. And the reason it wasn't of interest to them is that Bitcoin was too new and too raw, too much like the Wild West for them, to be willing to put any kind of serious business process on top of this blockchain, which they don't really understand and they don't really control and they don't really have anyone they can point the finger to if something goes wrong. So that's kind of what led us in a different direction because we saw that CoinSpark was simply at this stage, not of interest to the kind of people that we wanted to interest.

So the problem there was, I mean, you said, so was it the association with Bitcoin was one problem or was it also that you sort of don't have very much control, right? Because they're miners and just sort of you set it into network and then hopefully it will get processed. So yeah, there's a whole list of, you know, if you look at like a serious company that's listed on a stock exchange and then looking at this technology, there's a whole bunch of problems with it. So one is the association with Bitcoin, but that's cosmetic, you know, and that could change over time.

But there are things like the transaction capacity, right? that's, you know, still, after all the arguments they were blocked, is we're still stuck at a few hundred thousand transactions a day. There's a problem of the miners, which is that the people who are validating the transactions, are often in jurisdictions which, you know, Western companies aren't so comfortable with, and they don't really know who they are. There's the fact that an asset which is issued over the Bitcoin network is a bearer asset in finance terms.

A bearer asset means whoever's holding it has it. And there's no like a registry of who should hold it, and there's no way to kind of prevent it falling into the wrong hands. Now that, of course, is something that's very attractive to a lot of the people that are drawn to Bitcoin. And Bitcoin itself is like the ultimate bearer asset, because no one can stop you having it, and you can simply send it across the world in seconds. But bearer assets have been more or less outlawed, you know, if you look at it in the US, because the problem with a bearer asset is it's essentially something which is very small physically,

but which can represent a huge amount of value. And that kind of thing is very attractive to the types of people that governments don't like very much. you know, we can say terrorists or we can just say people that are evading taxes or money laundering, these kind of things. So there are assets in general are not very popular these days. And any asset that's issued over the Bitcoin blockchain is exactly that type of asset. Right, right. And then you, was that sort of, you saw these problems and you said, okay, we have to do something that people actually want. And then you started multi-chain. So we started talking to people. And specifically, we started talking to a lot of financial institutions

because, you know, the most attractive issuer of a dollar denominated token would be a government, right? But that's never going to happen in the next decade. So we thought, with the next level is you go to large banks. And so we started talking to large banks about this time of technology. And we realized that they were very interested in the technology, but not in the kind of aspect of it, which relates to public blockchains and to anonymous mining and that kind of thing. And the other interesting that was happening is that quite a few banks were actually tinkering with this stuff. And what they were doing in practice was they were,

taking some really good developers, pointing them at Bitcoin and saying, kind of download this code, and start tinkering with it to make it suitable for the kind of thing we'd want to do. And that process was happening in quite a lot of banks simultaneously. And it wasn't very easy because they had to learn everything from scratch, and it's not a particularly easy code base to work with. So having seen that happening in various places, I just kind of concluded that probably there was room in the market for an off-the-shelf platform, which contains the features that they're wanting to add,

but doesn't require them to actually spend a year coding it up themselves. That was multi-changed, basically. Yeah, so basically then what you built, right, it was a platform that if somebody wants to basically do sort of a fork of Bitcoin to run in a private environment with maybe some more features or changes, that, you know, instead of sort of doing it from scratch, they can just take multi-chain and, you know, configure that for the specific use case. Exactly, yeah.

So the product would try to model it after, from a philosophical perspective, is something like MySQL, which is just a black box, which provides a functionality, it provides, it's configurable, and you set up your database, and you grant your permissions, and you issue your transactions. So we try to, obviously, it's a different model than a blockchain, but we try to reproduce the experience as much as possible to be something like MySQL. It's time for a word from our sponsors, vaultora.com, the goal to Bitcoin Exchange. You know, when you start your company, things can start off kind of slow. Now, Valtura has really been taking off lately.

They found it in 2015 in February, and in only seven months, they managed to reach $1 million of trades on their gold to Bitcoin exchange platform. And then just two months after that, in November of 2015, they had already reached $2 million in trades. So Voltaire is really becoming a place where traders frequently go to trade gold for Bitcoin. On top of that, there's a software called the cryptocurrency automatic trader that has added support for Voltoro. Now, what does that mean? It's a little robot that can do the trading on Voltoro for you. So if you like to sit on the sofa and have your gold being traded for you

on Voltauro life, that's possible now. And you can learn more about that on the Voltoro blog. And we certainly know that we have some of these Ethereum autonomous organizations or other strange drones that want to make money listening to this and they are very interested. So that's a great service. And we're very proud of the work that they were doing. doing at Voltoro. Now, if you want to start trading gold, you can do so today. Head over to Voltroro.com. You can trade as little as one milligram. You don't need to give them take K-YC information. They are that good. And we would like to thank Voltau for their support of WebCenter Bitcoin. Okay, so let's then I guess move into multi-chain. Could you

explain in detail what multi-chain does and what problem is trying to solve? Yeah, sure. So I guess one easy way to describe it, maybe maybe to say how it differs from Bitcoin, the software, how it differs from Bitcoin Core. So there's three key ways in which it differs. Number one, everything is configurable. So every parameter of a blockchain is something that you can decide per blockchain and you can have multiple blockchains running with different parameters. So a parameter could be something as simple as the maximum block size, you know, how many transactions it can perform per day. It can be more complicated things like what's the permissions model, what? what type of transactions are allowed, what's the maximum amount of metadata, all these things are parameterised, that's the first thing. The second thing is it's permissioned, so there's a layer

of permissions on top of the blockchain which control who can do what, and the what can be connecting to the chain, sending and receiving transactions, being an administrator, issuing assets and mining or mining is perhaps a problematic term, creating blocks or validating transactions. And the third thing is that we brought support for assets down to the native level of the blockchain. So if you look at all six of the protocols which allow Bitcoin to be used to move other assets around, they all suffer from a certain technical difficulty because the Bitcoin network itself is blind to the information that they express. And that expresses itself in various ways in terms of, you look at counterparty and the Omni protocol, there's a delay there

in terms of you have to really wait for something to be confirmed in a block to know what happened. If you look at the color coins protocols, it's a bit better because they superimpose over Bitcoin's model, but they still suffer from the problem that you can put fake metadata in a transaction to say that there's some color coins there, but there aren't really some color coins there. So you always have to track assets all the way back to the genesis to know what's going on. Whereas if you bring support for assets as a native feature of the blockchain, so that every blockchain node is tracking and verifying the movement of every asset, then you get all the qualities you have of Bitcoin in the Bitcoin blockchain,

but you have it for every other asset as well. And that's kind of quite an important feature, technically speaking. So if we talk, because with Bitcoin, right, there's one native asset. With Ethereum, there's one native asset. So with chains like that, or, you know, then you can add assets in terms, for example, of smart contracts, through contracts, for example. But then here you have multiple native assets potentially. Is that correct? Well, it depends how you define native assets.

So if you define native asset to be something which every node in the blockchain monitors and contracts, then anything issued over Ethereum is also a native asset. If you define native asset to be something which is intrinsic to the blockchain and is some kind of token which the miners earn and which transaction centers have to use, then by default, multi-chain has no native asset at all. You can have one if you want, but by default, there's no native asset. Everything is just zero in terms of the native asset, and the entire purpose of the blockchain is moving issued assets around from one person from another. So if you compare that with Ethereum, then you could almost say that when you talk about multi-chain having native assets, that you have this like asset factory where you can say like, okay, create these assets and then,

you know, like they're created and they function in a similar way to like, let's say, contract on Ethereum or like Bitcoin on the Bitcoin network, except for the mining and transaction fees. Yeah, exactly. So technically Ethereum is very, very different, but maybe it's easier to compare it to how it works in Bitcoin. So Bitcoin assets sit inside transaction outputs, right? Sorry, I should say Bitcoin, the currency, sits inside a transaction output. And every transaction spends some previous outputs and then sends them to some new outputs. So that model whereby Bitcoin flows across a transaction from input to output is exactly what we do with assets issued over multi-chain. So any multi-chain asset sits inside a transaction output of a transaction and is actually encoded there inside the transaction output itself alongside the native currency, which is generally zero.

And then it can be spent by other transactions, which move it around elsewhere. Could you then have multiple, so you could have multiple assets within one multi-chain instance. So if you're an organization or several organizations working together and you want to create several different assets, perhaps one representing US dollars, euros, yen, what have you, one single private blockchain running over multi-chain could have all those assets embedded within it. Absolutely, and that's kind of the point, yeah. I mean, you can have essentially unlimited that number of assets running on a single multi-chain blockchain. And then we also did something which is a little bit unusual, which is we enable a single transaction output to contain multiple assets together.

And that's different from quite a few of the color coins models out there, which always separate them across different outputs. And that gives us certain things that we can do as a result. So if you have multiple outputs, multiple from different assets to the same transaction, it means basically you can do sort of, it's like basically, like an atomic swap, right, but within a single transaction. Yeah, you can do an atomic swap between two people with two assets. You can have two people with 20 assets and you can have 20 people with 100 assets.

You can build any kind of atomic swap you want with the model that we developed. So can we talk about the consensus mechanism in multi-chain? Yeah, sure. So to start with Bitcoin, you know, Bitcoin has this notion of proof of work. Why does it have proof of work? It has proof of work because in a, in an anonymous public blockchain, it's possible for one entity to mine under many different identities, even though they're just a single entity. It's the problem of impersonation or the

civil attack, right? It's exactly the same problem you have with online surveys that one person can fill out 10,000 surveys. So Bitcoin needs a way to prevent a small group of entities from taking control of the chain by pretending to be a large group of entities. And so proof of work is a way to do that because they basically say to a small group of entities. If you want to pretend to be a large group of entities, you can try, but you have to work extremely hard to do that, and it's going to cost you a lot of interest in a lot of money. So once you have a private blockchain, or specifically, once you have a blockchain where mining of blocks is permissioned, where not everybody can mine a block, then that whole problem kind of falls away, because everyone who creates a block

has to digitally sign that block to prove who they are, and then there's no impersonation problem, because I could sign a block with the identity that the chain has allowed me to use, to mine a block. if I sign a block with another identity, no one's going to accept it because it's just not on the white list. So as a result, the means you have of preventing minority control of the chain are much, much simpler. And so multi-chain uses something which could be called mining diversity. The basic idea of it is, and this is configurable as one of the parameters of a chain,

is you can define the level of strictness of a kind of round-robin mining scheme. So if you can imagine there are 10 miners, you have permission to mine at the current stage of the blockchain. So a very strict scheme would say that every single one of those 10-minus has to mine a rotation. And each one has to wait its turn after its mine for all the others to mine until it can mine the next block. And that way you prevent anybody from having control of the chain unless they've got the agreement of everybody else. So that's if you're very, very strict. But multi-chain lets you make that a little bit more lenient because the problem with being completely strict is that if a few of the miners just dropped off the chain or their server went down, you don't want everything to freeze up. So you've basically got a parameter in multi-chain, which defines how strictly the round-robin mining scheme is in fourth.

Okay, so if we had four miners, for instance, on multi-chain, and if you had set that parameter to say one, then it would be one, each block would be mined by one minor. But in the case where you set that parameter a little bit lower and you're a little bit more lenient about it, if one of those miners drops off the network, then it can pick up later on when he comes back on. Could you explain how that works?

Yeah, so let's say, let's take the example of four. So let's say you set the mining diversity to 0.75. that means that three of the miners are sufficient to mine a chain. So if one drops off, the other three can keep mining the chain indefinitely, and everything keeps working. If you set it to zero, then there's no constraint at all in any mining can mine any block whenever they want. So it's about balancing the risk of technical malfunction of some of the miners that they can't proceed. On the other hand, you need to balance the risk of, well, if you set that diversity too low,

then it is suddenly possible for a small group of those miners to get together and to take control of the chain or to mine a fork in secret and then to transmit it later on. So you need to balance those two risks. Okay, so in this example, if you had set to 0.75 and two of those miners were to drop off,

then what happens? That seems like a security vulnerability, right? Where an attacker who gains access to the network could knock those two off with the US attack or something like that? Yeah, so if you had it set to say 0.75, and two of the miners dropped off, then what would happen is that the chain would freeze up.

So transactions will continue to be transmitted over the network, but the mining would no longer be able to proceed essentially. So there would be no more blocks until one of the people that dropped off rejoined the chain. So do you still have, you know, hashes and the difficulty like in Bitcoin? Yeah, so we have, first of all, you have block hashes because that's just the way to identify a block. No, but I mean that like miners are hashing to try to get like, you know, a certain number of leading zeros. So nominally we do because we basically, because the ability to have mining being open or closed is another parameter of a chain. So you can have a public blockchain running off multi-chain if you want.

So we haven't removed all the code for proof of work. But if you're using private mining based on a white list, then essentially the difficulty is set extremely low. So it takes like a fraction of a second on a regular CPU to mine a block. So it's there nominally, but it doesn't really serve any purpose. And it's certainly not the basis of security in a permission blockchain. And so what if I now started mining lots of blocks, even though I don't have to write? Then what happens? The rest of the network will just not accept them?

Yeah. If you mine a block, then they accept your first block. Then you mine the next one. They'd say, no, that's not acceptable to us because you have to wait your turn. Because the mining diversity basically sets a minimum spacing between two blocks mined by the same miner. So the network wouldn't accept the next block. Do you also have things that, like, let's say, I'm going to go backwards. one block and start mining from there, like, attacks.

What does the security model here look like? Yeah, so you can have a fork in multi-chain, like you can have a fork in Bitcoin. It's a possibility. As in Bitcoin, it resolves itself by basically the longer chain being the one that's considered authoritative by the nodes. So it works in a very similar way. All the nodes in the network are aware of the fork. They've got their current version that they believe is the one that they're currently working on,

but they're aware of the fork as well. And then if the fork kind of gets longer than the current version, then they switch to the fork. So it's a very, very similar to Bitcoin. The way to look at it is really that the security model is actually exactly the same as Bitcoin. You just have a different mechanism of preventing minority control, which you can only do because you have identified permission minors. So I'm curious, to me it seems like, okay, maybe it works, right? But it's sort of like it feels like a hack, right? So have you also looked at like proof of stasis and like tendament? because it seems to me like, let's say if you have these four entities say you want to control the chain,

well, why don't users have all of them vote on every chain three say yes, the block is proof, right? Yeah. So there's a few things I can say about that. First of all, proof of stake. The problem in a blockchain with no native currency is stake in what, right? If there's no native token of that chain, then who's got a stake in what? Like, it doesn't particularly make sense. It would be a possibility for a future version where you just create a token whose only purpose would be to give people a stake in that token for mining.

You've got to look at block confirmations a little bit. If I may jump in here. So, I mean, you say proof of stake and what? And that's correct, right? Like, okay, you could, I mean, of course there's security deposit and stuff. But yeah, you're right. If there's no native token, then that can be a challenge. But also, because with proof of work, you say you don't have this stake in something,

hence we made it expensive. But here it's not expensive, right? So like... Yeah, it's expensive. The thing you give up when you mine a block is the ability to mine another block soon. That's a same. what you give up when you mine blocks. That's a kind of expense, but it's obviously not a financial expense. But I wanted to say that you should look at the, if you look at the Bitcoin blockchain,

there's two things that happen across the network. Transactions get transmitted and propagate within a few seconds, and then blocks should get transmitted and propagate, you know, also within a few seconds, but they take, they only happen once over 10 minutes. So in Bitcoin, confirmations in a block are extremely important. When you look at a private blockchain, the block confirmations are kind of less crucial. You need them, you need them for housekeeping, you need them to make sure that every transaction was seen by every no new, you need them to make sure that there's no conflicting transactions. But actually, because you know who your participants are, an unconfirmed transaction is really quite believable. And the role of mining is kind of much less than it is, or the role

of generating blocks is, is much less than it is in a public chain. You kind of need it there to make sure that things don't go wrong. But for all intents and purposes, you can trust unconfirmed transactions in a private blockchain, because if someone's double spending, then you're going to know exactly who they are and you can essentially take them to court because you know who they are and you've got some kind of contract with them. Let's take a quick break so I can take it to Paris. I stopped into the ledger offices and met with Eric Larchavec, Ledger's CEO, and he filled me in on the upcoming Leisure Blue. In early 2016, we are going to release the Ledger Blue. This is a personal privacy device

which runs on a C2 element, has touchscreen, NFC, Bluetooth and U.S. USB connectivity and it will be a full-fledged hardware wallet with a second factor validation of the transaction directly on the screen. It will be fully open source, you will be able to add your own apps and it will also be compatible with FIDO second factor authentication. Password are going to disappear and it will be replaced by this kind of cryptographically secure authentication. Ledger Blue will be certified by Fido and will give you the possibility to login on any website very easily just by signing a cryptographically secure challenge.

Ledger is making hardware wallets easy and convenient without compromising on security. If you want to get a secure setup for storing your Bitcoins, go to ledgerwalt.com and use the code Epicenter to get 10% off your order. We'd like to thank Ledger for their support of Epicenter Bitcoin. So is there a possibility where a private blockchain could be used by actors that don't necessarily know their true identity or pseudonymous? Can you imagine use cases for that or scenarios where that would be possible? So certainly you could use a private blockchain in a situation where the miners are known, but the end users are not known. For example, you can configure multi-chain to allow anybody to connect to the network and anyone to send and receive transactions, but for it still to be permissioned in terms of mining, in terms of administration and issue. issuing assets. So that could be a model whereby you have like a group of banks who are

collectively managing this kind of distribution ledger, but they're allowing anybody to connect to that ledger from a mobile device and the mobile devices are just generating their own keys and don't need to be permissioned. So that is certainly a possible use case for a private blockchain or a semi-private blockchain. I don't see a use case whereby you have this kind of private blockchain or permission ledger where you allow anybody to do the mining. There seems to be no interest in that because the whole reason to go to a private blockchain is so that you kind of know who's validating your transactions and so that you can trust them. I mean, the only way this could work is if you had some system to say, to switch out

the people who are allowed to do the mining, right? So you have that in multi-chain now. I mean, you have the administrator or collectively the administrators can add minors and can remove miners. It's not hard-coded when the chain starts. It's a permission that can change over time. Yeah, I've wanted to ask about that. So there is an administrator in multi-chain and that administrator chooses who is allowed to mine, does that administrator retain special privileges over the whole time of the chain, or is it just a sort of a set-up procedure?

So you've got, yeah, so they've got a couple of choices. So first of all, being an administrator is itself a commissioned role in multi-chain. And once you have multiple administrators, certain types of changes that are high risk, like allowing people to do mining, a subject to consensus between those administrators. So that's another parameter of the chain you can set. You can say we only allow a new miner to be added

if 90% of the administrators all agree on that minor being added. So administration is not necessarily centralized. It can be distributed between a number of entities. So there is also a notion of a setup phase in a multi-chain blockchain. So one of the parameters of a chain is you say how many blocks constitute the initial setup phase of the chain.

And during that set-up phase, a lot of the things that are usually strict are kind of not applied strictly. So, for example, in the setup phase, there's no issue of mining diversity, and in the setup phase, administrators can do things on their own that they can't usually do once the chain is running. So you do have the notion of a setup phase, which is kind of baked into the parameters that start a blockchain off, and then after that point, things kind of run for the long term. So could you explain sort of what types of permissions an administrator can give? So, for example, we were talking early about auditor notes. Could you have nodes that are able to make transactions?

So for example, like you had multiple partners or banks or something like that working together on the same blockchain. And then you may want to have external auditors come in and have read-only access. Yeah. So you've got that. So you've basically got six type of actions which are permissioned. Connecting to a chain, sending transactions, which basically means signing inputs. Receiving, which means appearing in outputs, issuing assets, mining. and being an administrator. So there's six type of things that are permission. So if you want to have a read-only access,

you essentially give connect permission to a particular address, but no other permissions to that address, and then you can see everything that's going on, and it can kind of download transactions and download blocks from the chain, but it isn't able to generate transaction. And aside from this scenario that I just described of external auditors, can you think of other use cases where that would be valuable? That's the one I keep hearing about, or auditors or the people use the word regulators as well. So governments could basically have a real-time view of what was going on in this particular trading environment, as opposed to the situation today where in many cases they have to kind of request reports from each of the individual actors

and then wait for the report to come back and then kind of compare and contrast and we can sell all that separate information. And would there be any way for something here if these regulators would like more transparency and, you know, this is what blockchain's enable, but is there, would be a way for, sort of the core of the multi-chain, so like the miners or the people allowed to make transactions to spoof or to falsify the information that makes it out to the read-only nodes? Is that possible?

If the read-only node was only connected to, you know, one other node in the chain, then obviously that node can give it any kind of nonsense it wants. But assuming the read-only node is connected to many, many points in the chain, then again, it's like, It's kind of a very similar question to the one that you would ask about Bitcoin. Is it possible for a wallet to be given a false view of what's going on in the Bitcoin blockchain? And the answer is yes, but only if it's connected to points which are maliciously colluding together to give it that false impression.

So one of the challenges here, too, I mean, so privacy, of course, is sort of an advantage in some ways, right? Because you can say, okay, just like these five entities administer the chain together because we don't want others to see what's happening on this. But at the same time, when you started talking about, like, you know, you mentioned Ranka put many assets on that. Let's say you have 100 different assets, lots of entities involved. Like, you may still, like right now, transactions between different entities may be happening in private. Here, like, everything is visible.

Like, how do you think about privacy in this context? Yeah, so absolutely. I think that, you know, and there's a lot of people are sticking their head in the sand, ignoring this question when you're talking about applying blockchain. in the finance sector. I think it's absolutely the key question, and it's the elephant in the room, which is that if you look at the role of central entities

in the finance world, yeah, it's true that one of their roles is to manage this authoritative, synchronised database of transactions, and that job that they perform can be replaced by a blockchain. But another one of their roles is to act as a Chinese wall

between the participants in a marketplace so that bilateral transactions that take place between two entities aren't visible to any of the other entities who are kind of connected to that same network. And blockchains, by default, at least, completely smash that model apart, right? They make everything visible to everybody.

Not necessarily all the offers going around, but certainly all of the actual settlement transactions which move assets around are visible to everybody. Now, there's a whole bunch of possible approaches, strategies for dealing with that. Some of them have already been implemented, like the confidential transactions work by Blockstream, which is very interesting,

which hides quantities, but doesn't hide addresses. There's kind of a long-term research project actually going on here with a group based in Israel, on zero knowledge proofs, which is can we actually take the entire process of verifying a transaction and put that under the umbrella of a zero knowledge system, which essentially means that somebody can prove that they verified a transaction

without revealing anything about the content of that transaction, and that proof can be examined by other people without knowing the actual content of that transaction. So that's kind of an ongoing research project. And then you've got possibilities of, like, certain people seeing everything, and then other people seeing only some things or maybe the mind to see everything

and then they only reveal certain things to other people. But they use a kind of hash to prove that's the same. So a question on that. So let's say you do achieve the situation that, you know, you can verify that things have been done properly but you can actually know anything about the content of what's going on. I mean, I can see that being useful in some cases, right? Like let's say if you want to do...

Actually, if you want to do something like Bitcoin, this is perhaps not a bad idea, right? Because you want to have anonymity, actually, for like, electronic cash. But I think it isn't one problem here, too, that you actually sort of destroy one of the big benefits of blockchain, which is, you know, auditedability and the ability for people to write applications on top of it, do analytics, like all kinds of things that, you know, all of a sudden fall away. It's a complete trade-off, right? I like to compare it to the uncertainty principle in quantum mechanics. Like you can know the position of something or you can know the speed of it,

but you can't know it at the same time. And it's kind of the same thing. You can either have a transparent blockchain or you can have loads of things hidden, but you're not going to get the benefits of one and the benefits in the other at the same time. So I guess a lot of what the industry is trying to figure out right now is where is the right balance between these two things. And that very much depends on the use case. There are some use cases like trade finance where probably there's not that much need to keep

things confidential because it's not like a very competitive environment between parties. Then you've got other things like, you know, high frequency trading of currencies where basically the banks are all trying to one up each other and make profits off each other. And in those cases, obviously, they're going to want to hide as much as possible from each other. So it depends on the use case. And I think absolutely you're right that this is something that needs to be resolved and it's something that not enough people are talking about right now. Let's take a short break and talk about hi.mee.

Hi.comi is a VPN provider. And if you don't know yet why you should need a VPN provider, let us help you. I'm sure you were like me and when all the crazy revelations came out during the Snowden time of all the spying that is being done by the NSA and other government agencies, you were shocked and you said, not with me, not with my own rights. Now, the way government agencies can spy on you, there's many of them, But the most easiest way is by simply going to your ISP and getting all your traffic capturing all your traffic. And the VPN can protect you from that.

It can give you a secure tunnel from your computer to any of the exit nodes all over the world so that all your traffic goes to this secure pipe that's encrypted and cannot be intruded on. And with Hike.m. You can choose any of their 30 exit nodes all over the world so you can enter the internet in a secure location. The best thing about Hyde.me is that they have a free plan, which includes two gigabytes of unthrottled bandwidth per month. So you can go to Hyde.combe slash Epicenter to create your free account. And when you use that URL, you'll automatically get 35% off if ever you decide to go premium. Now the premium plans are really great. They include unlimited bandwidth, access to all of the 30 exit

nodes that Hyde.m. provides. And you can install it on up to five devices at a time so you can have this running on your phone, your tablet, your computer at work, your personal computer, and just be completely protected all the time. And of course, high.combe accepts Bitcoin. So we'd like to thank high.combe for their support of Epicenter Bitcoin. So another question that often comes up and that gets a lot of people very heated, at least in certain communities, is the sort of question of, is this actually something new? Like, you know, when you start removing proof of work, when you start removing actually the ability for sort of anybody to participate in this process, you know, people often talk about censorship resistance, things like that. And now all of a sudden you have a known group that adminishes the network.

And, you know, often said, like, isn't this just a private database? Like, what's the novelty here? How do you think about this issue? Yeah, so I've thought about this issue a lot because, you know, I have to figure out if we're wasting our time or not. And it's certainly less new than a public blockchain like Bitcoin, but I believe it is still new. And if you look at the transaction model of a blockchain, the key thing which it enables, which is not enabled by today's database platforms, is the ability to have a database which is shared by multiple entities who don't trust each other, but who will write to that database without requiring a central party to manage that database.

That's the key thing which it enables. And that's new. That's something that if you look at today's database platforms, they simply do not, they do not allow that. Maybe they will in future. It wouldn't surprise me at all. If one of the things that happens as a result of blockchain is that the version of Oracle that comes out in three or four years time

has this functionality built in. But right now they don't provide that ability to have a shared database between people who don't trust each other without requiring a central gatekeeper to authorize and to kind of check transactions. So adding this into existing databases, how would that work? Is that simply a matter of them turning on some features

or is it more a matter of them actually taking technology that's being developed in the blockchain space now and sort of building a new database paradigm based on that? Yes, so that's an open question, whether it would just be a matter of, you could just do it as a few bolt-on features in today's existing databases or you might want to actually redesign what this database should look like as a result of this new functionality. It could go either way. I honestly don't know the answer to that question yet because so much of it depends on where the key use cases are of this technology.

And so touching on those use cases then, what would then be the use cases for private blockchains and versus public blockchains? Would there continue to be a use for public blockchains such as Bitcoin? Yeah, I think actually that this is something which maybe is becoming clear over time, is that although there is some technological relationship between public blockchains and private blockchains, they're actually for completely different purposes. I think public blockchains certainly have a use. Apart from Bitcoin itself, I think the ability to embed metadata in public

blockchains has a huge number of applications and the use of this opereturn feature is growing extremely fast if you actually look at the statistics on Bitcoin, which we do look at. And then private blockchains are essentially a database technology. There are database technology which enable a bunch of new entities to create a database which works in a different way to have databases work today. And that class of database will solve a set of problems which, cannot be solved today. Well, I think that one really valuable use case for Bitcoin as a public blockchain is simply

the fact that it's there and it's accessible to everyone and that everybody can use it regardless of whether they're just an individual or an enterprise trying to develop some sort of a digital asset system. I think that that is the primary value of Bitcoin that public, private blockchains don't offer since you have to implement all this infrastructure in order to get things running. Yeah, I mean, I'd agree with that. I mean, if you think about what Bitcoin is, putting aside the currency itself, Bitcoin is a global decentralized database in which anyone can put anything they want

without being necessarily traceable so long as they're willing to pay the cost, right? And the cost is essentially, from the perspective of the end user, will be, you know, how many cents per kilobyte? It costs to put information in this global repository. And I absolutely agree with you. The fact that that censorship free is hugely important. It's also going to make it probably much cheaper than it would be if it was centralized because no one can really skim a tax off the top of that

and without being in competition with every other miner in the world. And yeah, I think that's hugely valuable. I mean, I'm personally interested in the use case of the Bitcoin blockchain for family trees. The idea that, you know, you could stick your family tree in the Bitcoin blockchain and then a couple hundred years time your great, great, great grandchildren could pull it out. To me, that's kind of an interesting use case. And it's just the kind of thing that was never possible for. We didn't have this decentralized global database.

that was accessible to everybody. So absolutely, I think that's what I believe the Bitcoin blockchain will end up being. I think Bitcoin will end up being the currency that fuels this global repository rather than being its main application. And its main application will be simply a permanent timestamp file system for anything that anybody wants to store and make globally available and globally replicated. Okay, that's interesting. So you phrased it before that, you know, Bitcoin is this not a new thing.

And then if you talk about private blockchain, it's just a new deal. database. But then do you think of this as something, is it an incremental improvement over what we have now? Or is this something like radically novel that is like, you know, is it going to cause a little change or is it going to change everything? Well, someone wise, in fact, several wise people have told me recently that if you look at these type of technologies, they're almost always overestimated in terms of impact in the short term and underestimated in terms of impact in the long term. And I think maybe that applies here. You know, it's going to take a long time for blockchain or the shared database technology to make a significant difference to the way in which

things are structured in the economy. But if you look at the economy and how it's structured and how things work in many, many industries, there are often, there are many, many entities whose primary role is to maintain an authoritative record of something. You know, the finance industry, the supply chain industry, insurance, legal, et cetera, et cetera. And if that can be replaced by a different technology, then I think it's likely to make a large difference over time. I don't think it's going to transform the world, but I think you might end up seeing, similarly, you have some of the other technologies that have come out, maybe 5 or 10% of the current workforce ultimately being displaced by this technology, and that's quite a big thing.

Right. I mean, personally, I think it, I totally agree it's going to take a long time, right? It's going to take a really long time for a lot of these technologies, both on the sort of public blockchain side and other blockchain side to get somewhere. And I also think, you know, maybe right now it's sort of like divided into these two camps. At least that's the way the narrative is sort of told. I don't think that's going to be like that. I don't think it's going to remain like that. I think there's going to be all kinds of different hybrids and like weird interactions, interoperability between them. And I think when we talk about the change, I mean, it also starts interesting when you think about sort of the nature of a company,

you know, because if you, because one of the advantages, if you do a company, right, then you can have control about all these things inside and maybe you wouldn't want to trust someone else to do this essential part of your business because, well, you can't verify it. But all of a sudden, if you can put that business logic on a blockchain, well, maybe you don't need that company or maybe you start having a complete just sort of segmentation, which we have already had in many areas to some extent, but that could just go to completely different level. So I think it's, I see so many, but it's going to take a long time. That's definitely true.

And probably in the short, medium term, the effect is not going to be that big. I think we will be here in 20 years to try to figure out the implications of blockchain. Yes. Okay. So let's say, let's just, so we got to put that in our calendar that in 2035, we're going to get you on back on again. If I'm still around, it's a pleasure. Yeah.

Cool. So what are the best use cases for us? So public blockchain, you mentioned this like data repository, like censorship resistance data repository, which obviously is interesting if you want to sort of, yeah, proof of existence is the best example. right, like you improve this thing has existed at time X. You can put that in the Bitcoin blockchain and sort of anybody knows. And of course, actually, I think probably still the best example for Bitcoin or public blockchain is, well, sort of decentralized currency is a great example, even though it has its problems.

But what about private blockchains? What do you think is the best use case in maybe in the near term and in the medium term? and longer term. Yeah, so if I completely knew the answer to that question, I'd be happy and we're still trying to figure it out. But, I mean, again, because I think it's a shared database technology, you have to look in the economy for places where you have multiple entities who need to maintain a shared record between them.

Right now they need to go through some kind of central entities. So the finance sector is a really, really obvious one, and they've also paid a lot of attention to this because Bitcoin kind of came into their radar a few years before, and so they're kind of keeping track with other interpretations of that technology. I think the legal profession, there's many cases where what lawyers actually do is just record and timestamp something, and that could be done on a shared database in a way that would maybe reduce what lawyers do to more like actually using their ability

to formulate words and terminology in contractual terms rather than providing this kind of function for the economy of being a trusted kind of a source of things. I think accountants as well might be different because as you mentioned, there's the ability to have an auditor role, who can see what's going on in this kind of shared database or blockchain, and then a lot of what accountants do could be replaced by software. So many different possibilities. But I think, you know, people are still figuring it out as well. The other thing that comes up a lot is supply chains. If you look at how supply chains work right now, there's some really, really antiquated processes that take place. You know, supply chain sounds like a niche until you realize that actually

almost everything that we consume and create is actually moving across the world one way or another across some supply chain. You know, there's things like builds of lading and letters of credit and these physical documents that have to make their way around the world. And that could quite easily be replaced by some kind of shared database between all the participants in a particular process so they can move assets around over a shared database or a blockchain. So many, many possibilities, but I think we're still figuring it out.

And I think it'll take years to get clarity on it personally. This magic word is database, D-A-T-A-B-A-B-A-S-E. Head over at let's-talk-B-C-C-B-C-C-B-C-N-T-N-E, enter the magic word, and claim you're a part of the listener award. So you mentioned, like, the example of trade, international trade, and things like that. Do you see this as being, you know, one big public database? will be created, you know, maybe using, or maybe a bunch of big databases for different applications will be created, or do you think it will be thousands of databases where it's like...

I think it'll be millions. I think that, you know, how many databases are in the world today, right? I don't know how many billions of databases are on the world today. Each database represents a particular problem space, the particular set of information that is a group of people are interested in. I think it'll be exactly the same for blockchain. Right. So you'll have like, like, actually the parties.

interested in that transaction, you know, set up a database or set up a blockchain. I mean, that's how we design multi-chain to be, you know, it takes a few seconds to set up a blockchain and a couple more seconds to connect to it from elsewhere. So the idea is that you could just kind of throw away, right? You make one, you use it for whatever purpose you want, and then you can make another one and you can run lots at the same time. Okay, cool. So you've also written an interesting blog post about smart contracts and blockchain, and

it was very long, but it was very interesting. Can you talk a little bit about your fault regarding running computation on blockchains, as we of course know from lots of smart contract blockchains that are now, well, I guess mainly Ethereum and in the private blockchain space sort of, or eras in the permission blockchain space but building on the same smart contract capability. What is your opinion of that? Yeah, so if you look at the model of what a blockchain transaction looks like, You've got a continuum, essentially.

On one extreme, you've got a Bitcoin transaction, which is extremely limited, extremely simple, but has some very, very nice properties in terms of the ability to run many of them at the same time in parallel, if they're not to interfere with each other, not to depend on each other. And that's one end of the kind of the spectrum. The other end of the spectrum, you've got an Ethereum transaction

is essentially a message that can trigger a general purpose piece of code that can do anything, right? So it can take a long time to process. it can end up sending messages to other pieces of code, it can end up having to modify its database and through the messages it sends, modify lots of other databases as well. And that's extremely powerful, obviously,

because as soon as you're true and complete, it means you can actually do anything which a computer can do. But the problem with that type of transaction is that it doesn't have good performance properties and especially doesn't have good concurrency properties. So you can't run two Ethereum transactions in parallel and say, well, you know,

we don't really mind what order we processes in because they don't really affect each other, because you can never know that about an Ethereum transaction, because every theorem transaction can, in principle, do anything. Now, there's ways, I mean, the strategies for dealing with this, but the basic thinking behind my piece was that by doing general purpose computation on a blockchain and requiring every single node to perform that computation for every single message,

the small problem you have is that the computation can end up taking a long time. That's a small problem, but can be solved through gas in a public blockchain and some kind of time limit in a private blockchain. But the big problem you have is your model of transactions is not conducive to high throughput and to having concurrent transactions running at the same time. And one of the ways in that, in ways in which that expresses itself, is that in an Ethereum-style transaction, until the transaction is confirmed on the blockchain, you have a lot less confidence about what the outcome of that transaction is compared to a Bitcoin-style

transaction or a multi-chain transaction where you can be pretty confident that unless someone is deliberately attacking the network, you know what the outcome of that transaction is going to be. So there's essentially a trade-off there. And my view of that trade-off is obviously it's going to depend on the use case of where we should fall on that spectrum, but that may be the right way to solve that trade-off is to have two layers. So you'd have a low-level transaction model where basically you'd have Bitcoin or multi-change-style transactions,

which are quite simple and quite restricted in what they can do. But you can still embed inside those transactions information representing general computations, whether it's the contracts that define those computation or the messages that trigger those computations. And therefore, those nodes who want to process those computations can do so, but it's not something that holds up the transactions that take place on the blockchain, which are much more simple in terms of what they achieve.

But, you know, as I mentioned in the post, it's something that I'm still trying to figure out for myself what the right model is in terms of, you know, this trade-off between flexibility and performance. So in this example, I think we have to maybe unpack this a little bit because I'm afraid this might be confusing to people. Because, first of all, let's talk about concurrency. How exactly is that different?

So can you explain how is it possible with something like Bitcoin to have concurrency? Yeah. So the idea of concurrency, I mean, concurrency, literally speaking, means you can process two transactions simultaneously. But because we're talking about a decentralized network when messages are moving across and there are time delays involved, you can also talk about the fact that if one node sees one transaction and then it sees a second transaction and then a different node, sees the same two transactions in a different order, how confident are you that those two nodes

are going to have the same interpretation of those transactions? So in Ethereum, you don't have as much confidence as you have in Bitcoin, because every transaction can potentially affect every other transaction. In other words, one transaction might make a modification to some information somewhere in the blockchain's database, that leaves the second transaction to do something different

than it would otherwise. Whereas in Bitcoin, because the transactions explicitly label which other transactions they're dependent on and which other transactions they can affect, you're able to, in most cases, process two transactions in a different order than in different nodes and yet still know that you're confident that those two nodes are going to reach the same outcome. So this would be relevant if you're talking about transactions being in different blocks, right?

Or even within the same block. I mean, it's also relevant if you're talking about two transactions which are seen before they're in a block as well. Right. But so if it's in the same block, I mean, with Ethereum, so let's say, you're sending two transactions that modified the same state, and then one Ethereum minor gets A first and then B, the other one B first in A. Are you saying that this would actually cause different results?

Yeah, absolutely. No question. This is interesting. The transactions have to be processed in the order that they appear in the block. If you look at the Ethereum white paper, it talks about Ethereum being a global state machine, right? So the idea is it's a global state of the Ethereum network. And each transaction is a transition to a new state, a new global state. So yeah, the order of two transactions, even within the same block can matter. Yeah, so I guess the remedy around

this is, yeah, so I guess that means you have to deal with it sort of on an application level often. Yeah, you could deal with it on an application level. You could say that we're willing to wait for a block to come in to process the transaction, you know, to be confident about the outcome of that transaction. Then you can be more complex. although there's still the chance that you're on the wrong fork. So you might have to wait for a few locks to be really confident about the outcome of a transaction. Well, yeah, you could solve it on the application level. But the point is that the blockchain itself, the blockchain engine itself, can't, excuse me, can't look at two transactions and say these are independent.

Whereas in a Bitcoin-style blockchain, it can look at them and say these are independent. Right. And so then you say, like, well, let's take that logic. Let's put it in sort of like an up return, no, like let's hang it into the transaction. And then, well, if you are interested in it, then, you're interested in it, then, you execute it, if you're not, then, well, it's just like data, ignore it. Exactly. But then how does that work? I mean, who's going to verify how those entities that are interested in that particular code

verify that? I mean, presumably they could come to different agreements about what that means, no? No, they couldn't. I mean, if that's a symbol. But they could lie about it. Oh, of course, they could lie about it, of course. But the point is that the data inside the blockchain, which is, you know, some nodes care about and some nodes don't care about, but the data representing those computations is fixed in the blockchain, right? No one's going to disagree about what's written into the blockchain.

That's how to work. So, and the rules of how to interpret that data are also properties of the blockchain, which everyone has agreed upon, the EVM, the Ethereum virtual machine. So there's no way that two honest nodes can get to a different answer when evaluating or executing the code in a blockchain. That is true. but the big advantage is that it's sort of explicitly in the consensus thing that like, oh, the chain it says, like, what result it came on. Here, here, I mean, maybe I could prove that, hey, I did it the right way. You didn't.

But then, I mean, who is going to, like, if we don't agree on that, like, what entity or who's the judge? So, yeah, you're talking about a field in the Ethereum blockheader called a state route, which is essentially the field which represents the entire state. of the chain as of the end of that block, and that includes the outcome of all the computations that are performed. So in a sense, what I'm proposing is get rid of the state route, right? So what you lose is this constant affirmation

to all the participants in the chain that they've actually got the same outcome from their computation, and then they can all trust each other. But I think it's a non-problem. I'll tell you why I think it's a non-problem, because if I make a contract in a PDF file, right, and I send that to you by email, I don't then phone you up and make sure

that your PDF reader is giving you the same information on your screen as it's running on my screen. Like, we know that we're running the same client, and it's running the same thing. And if someone has a weird PDF reader on their computer, which changes the amounts of money and a contract, which they view, well, they can do that, but it's very, very easy for any court that ends up being called upon to prove that that's a malicious one because they just download it from the internet, and they run that the one they get from the internet. So you're right in theory that there could be a conflict between different nodes because

you haven't got this constant affirmation, but they could just conflict anyway. I mean, one of them could just change the code of their Ethereum thing to pretend that they agree with the state route in the blockchain, but actually give you a different outcome when you query that node. So nodes can do anything when they're running on someone's computer, but I don't think it's, I don't think it makes the chain any less secure, not having... But if I did something funny, so my note does something funny, well, that does not going to change the sort of global state of the chain, right? Like for me to actually do some fake data in there or some wrong outcome or something like that, well, I have to somehow, you know, take over that process of updating it. Versus if I just locally run it, I can do whatever I want, and nobody can really tell me,

okay, this was wrong. I mean, you may be right that. You could do the same against the chain. You could modify the code of your node so that it pretends to agree to the state route of the chain, that's running a parallel process, which is writing something different into a separate copy of the database. Right.

I mean, really, what you sort of talking about then is like proof of existence, right? The state route is not, I mean, the state route is not proof of existence. No, but what you're talking about? So the chain would act to be a proof of existence of the content of the chain, of the content of the computations, yeah.

Right, exactly, right? Yeah. No, I can see that being, I guess in some instances that could be useful, right? if the computational complexity and cost is high, right, so that people can't actually execute it, and if people know each other so that they have the recourse to go to a regular court and, like, with that evidence and say, hey, you know, here's how it happened, you know. So if basically you want to cut the cost of the computation.

That's all you have now, right? I mean, if all you have now is you still have to go to court, if you want to, if you want to sue somebody based on what happened to the Ethereum blockchain, you still have to go to court. So all you've got is you can waive the state route at the judge instead of waiving the content of the blockchain at the judge and telling the judge to go run it for himself. But in terms of the actual risk and security, it's exactly the same.

So before we wrap up here, let's talk about this company that you founded Coin Sciences. So among other things, it is developing multi-chain. Can you talk about some of the applications that you guys are building with multi-chain? Yes, so we're not actually focused on building applications and our main thing where we're helping certain people who are building stuff on top of multi-chain

to do that, and we're doing a little bit of consulting work to help them do that, but we're very much focused on the tool itself. So the approach we take is that, just like a, you know, you take like a regular database, the people that develop a regular database don't develop applications, generally speaking, for that database. They develop an engine, which anyone can use to build their application on top,

and that's kind of the attribute that we're taking with multi-chain. So we're building the engine. We're doing some stuff like right now we're building an explorer so that people can have an easy graphical-use interface, that gives them a view into what's happening on the chain. But generally speaking, our focus is on the core technology which will enable other people to build applications. Are there any other applications that you can talk about?

Yeah, I can talk about a few of them in a very general sense. So tracking the movement of physical objects across the world within a large organization, a shared scheme between multiple companies who want to share and track the things between each other. I kind of got to remain a bit vague because I've signed a whole bunch of NDAs with the people that we're working with.

But you're talking about either within a large organization or between organizations, having a ledger which represents the movement of physical objects or of assets and which are financially in nature. And so what is the future here for multi-chain? Like you mentioned earlier that this was sort of an initial version and that in the future something a bit more robust would be developed. Tell us about that. Yeah, so there's two options. And to be honest, I haven't yet decided which one makes sense. One is to focus on multi-chain for a very long time and create like a premium, you know, have an open source version and then have a premium version, which has a whole bunch of high-end features relating to security and to, you know, logging and that kind of thing, which aren't of interest to hobbyists, but are of interest to large companies. The other option is to write something from scratch based on what we've learned from how people are using multi-chain, which is kind of a high-end blockchain engine, which is dependent at all on the Bitcoin code and works much better in terms of enterprise requirements.

And to be honest, those are two possibilities. we're learning all the time and we're trying to discern which one of those makes more sense. And as things currently stand, the future is open. Okay, well, thanks so much, Gideon, for coming on. My pleasure. Thank you very much for having me. Okay, so yeah, thanks also for listening. We put out new episodes of Episand and Bitcoin every Monday. You can get those on any podcast player you can find on Apple and, of course, Android as well.

And you can also get the video versions on YouTube. that's on YouTube.com slash episodepc. And we are still running this thing, which is this t-shirt competition. So basically you have to leave a real, let us know, and we'll send you a t-shirt. A tiny bit of heads up is that we're out of T-shirt. So it's going to take a little bit longer, but you will get it.

So thanks so much, and we look forward to being back next week.