DEBUNKING BLOCKCHAIN

Michael Salmony 0:12

Hello, my name is Michael Salmony and I would like to welcome you to another episode of the TPT, the payments trilogue. And today we have a special guest Lars from Giesecke+Devrient, because we wanted to talk about blockchain, what is real and what is hype. This is a topic quite close to me. Since a hundred years ago, I studied computer science and then worked for a long time at IBM. So,

Javier 0:15

.

you

Michael Salmony 0:41

a little bit of a background on computer algorithms, on unscalable systems, and I've always been a little bit confused why suddenly now, only now, it is possible to do conditional payments, to do distributed consensus. These were all things that were actually developed when I was a student. So Lars, very welcome to you. Please enlighten us and tell us a little bit about who you are and where you're from.

Lars 1:06

Thanks Michael for the introduction and also thanks everyone for having me. my name is Lars and I also study computer science. I even went as far as getting a PhD in it, in theoretical computer science to be precise.

But now my career is a little bit different. so my current job title is Chief Evangelist, which is of course a bit unusual. what it means is that I explain technology to banks and central banks and financial institutions, and concretely the technology that I'm focusing on is anything related to digital currency. So that's CBDC, central bank digital currency, but also

stable coins, tokenized assets, tokenized deposits, and so on. So everything that's sort of related to that. And of course in that space you cannot have a conversation without also having a conversation on blockchain. in particular what's the strengths and weaknesses of that technology and what use cases are they good for. And I know that the season the episode title is Debunking Blockchain, but I think we can bring a little bit of nuance in here, I guess.

Michael Salmony 2:08

That's perfect Lars. So maybe we can start with a programmability topic. I mean, it seems to me I can get out of my Uber and the payment is made conditionally. Why do we need a sudden new programmability at the lowest level in the money?

Lars 2:23

Yeah. I I think this is an important question. And if we take a step back, like let's let's say we have a bank account, right? All of us have a bank account with some retail bank, and if you were to set up some conditions in your bank account for how money moves, pretty much the only thing that you could do today as a retail user is set up a standing order, right?

So you can tell your bank, okay, every month I want to make this transfer, for example, for my rent, or I wanna pay off some credit card debt or whatever. Like this is basically the only thing that you can do. And then if you're paying with a credit card, the only thing that you can do there is sort of like putting a hold on it, and then this hold will be released or it will be finished after a week or something like that. So in in terms of retail applications, you're quite limited in what you can do.

You cannot set the conditions like if my account exceeds 500 euros, then move the money to a savings account, or maybe what you can do is you can sell some stock if the price drops below a certain level. But in terms of what you can do as a user, it's quite limited. If you're talking to commercial customers, right, so to businesses, they can do more, right? So they probably have some kind of ISO interface to their bank, they have some API that they can access.

and they can move money automatically based on whatever they put into their ERP system. but still I think the the reason why we're having this conversation is because you still cannot have like arbitrary stuff that you can do. And one of the main USPs or one of the main claimed USPs of Ethereum when it was launched is that suddenly you have a programming interface that lets you do pretty much everything, right? It's almost a Turing complete programming language.

and you don't need to ask anyone, you can just put your code on the blockchain, it will execute. you don't need to do anything to make it execute, right? You just deploy it and then it self-executes. And I I think the the idea behind that was that you can be autonomous, you can do whatever you want. and that s idea sort of is is now discussed outside of its context. So now as you mentioned, the the discussion has shifted towards, well

If I want programmability, I need blockchain, right? So somehow instead of discussing what we can do with the traditional technology, we're now only discussing it the other way around, right?

Michael Salmony 4:47

Very good. And if I hear you right, I mean, it doesn't solve a problem for the corporates because they have ERPs and all sorts of programming methodologies. And I would question whether the normal retail customer wants to write a smart contract in a new programming language, right?

Lars 5:03

Yeah, that's that's that's that's two kinds of worms that you mentioned there. So maybe we can talk about the the the retail user first. One of the main criticisms here is that smart contracts probably don't have legal binding power. Because in most jurisdictions, if like for for example, Michael, if I wanna buy your used bicycle, right, then we can shake hands on it and we can probably like make a a draft contract or w something like that. but

That that is the only way that we can make it legally binding. If you write a smart contract, it's not gonna be legally binding because our contract needs to be in German, right? So there's a whole issue of customer protection and so and so on going on there. And for the corporates, I mean they can do a lot of things today. another aspect, so I just want to avoid the criticism on on this point, is that

When you make a smart contract, you don't need to trust each other necessarily, right? So you can write that code and both parties can look at the code and say, well, we accept this code, and then it's sort of self-executing. Now, another question is, of course, what happens if then there's a later disagreement, right? How how can you then go through a court and enforce something? Maybe something you put into the smart contract is actually not legal in your jurisdiction, and so on and so forth. So so that's a whole can of worms how to how to make that sort of have this expressive power that you're used.

to in in in in your like, you know, daily business.

Ralf Ohlhausen 6:33

Could I ask could could I drill a little bit deeper? Because I think what what you're saying is that one of the biggest promises of blockchain and the whole DLT and then all of it is this automation or well programming of of payments or automation of payments based on smart contracts. So smart contracts is the buzzword. And you're you're you're just

Lars 6:35

Of course.

Yes, I think so.

Ralf Ohlhausen 6:57

Debunked it, right? so basically saying, okay, the concept is nice, but it doesn't hold up legally. That's what you're saying, right?

Lars 7:05

Yes. But I think I I I want to emphasize that there's not just the promotion aspect, but also the consensus aspect, right? So many people, many proponents of blockchain will claim, I mean it's cool that you can automate stuff in your own ERP, right? You can write some conditions or you can define some conditions in the supplier's ERP, but what about the the buyer, right? So what happens if the supplier and the buyer they agree on something in advance and then somehow the payment doesn't get through because someone

quite basically walk back on their commitments. So you have this aspect of probability, but you also have this aspect of consensus and in particular trustless consensus. because if you have two parties that don't trust each other, how are you gonna enforce anything? And well of course the traditional unf answer would be through the courts, but the blockchain answer would be through the smart contract, because the smart contract doesn't need enforcing because it's just there. It it just executes.

Michael Salmony 7:58

So you hold up this smart contract with a special language and show it to a judge and he's supposed to say that you're in the right.

Lars 8:06

Kind of. I mean this is the we're now getting really into the the nitty-gritty details here because if we consider like a hypothetical use case of trade across borders, right? You have a supplier and a purchaser and they're making a trade across borders and they're somehow codifying their commitments in the smart contract. Now the big problem is that the smart contract doesn't know when the purchase has actually been shipped. Right? So you need always some kind of information fed into the smart contract and

some people will say, actually, you know what? the shipping company could do it. And there's been experience around it. There's been some proof of concepts done around it that you have these kinds of like trusted arbiters that would then say, Okay, now the shipment has been made, and this means also that the money can be released. But then you're just basically shifting the trust from your a buyer to a third party. And there's another big problem here. so I have

I don't have an economic background, but I learned that the term for that is working capital. Because in a smart contract, you always need to commit the amount of money that you want to pay pay in advance. So when you're making the the purchase agreement, you need to already pay into the smart contract, and then it just gets paid out. And in the meantime, in these 30 days or whatever, how long or how long it takes to ship, this capital is just locked up. So that's also something that businesses, you know.

Sometimes small businesses like this because they get a guaranteed payment if they're selling something, but big businesses they don't like it because well, they don't want to lock up their capital all the time when they're waiting for shipment, right?

Michael Salmony 9:39

That's a really good point.

Ralf Ohlhausen 9:40

Well so so but but

how how else should we then automate the payments if not using this fancy new technology of smart contracts? So what are what are the alternatives?

Lars 9:51

Yeah, that's a that's a very good question. And my answer to this question, if we wanna already skip to my possible solutions to this, would be to enhance just the open banking APIs and interfaces. Because right now I think it's there's a I I think I I think it's there's a fair point to be made that banks and and PSPs don't offer a lot of flexibility to their customers in in the like in how payments are initiated, in how payments are processed, in in how

Michael Salmony 10:04

Yeah, well, thanks, man.

Lars 10:21

Can conditions can be attached to payments. And that is something that that is sort of a trend that's I think coinciding with digital currencies, right? Open finance has is orthogonal orthogonal to digital currency, right? But somehow these two trends are emerging or accelerating at the same time. And I feel like we're not putting enough focus on on the whole API aspect. Like how can you write programs in a way that we used to write programs for the last decades?

But use those programs to move money around. That's that seems strange to me as a computer scientist because when I first got into this finance field I was like, how are you even how are we even doing things, right? If if you don't have an API, how can you do anything?

Ralf Ohlhausen 11:03

Yeah, you you just stole my thunder because my follow-up thing would have been exactly this, because I I was saying, yeah, I don't know if you're familiar with the SPA SEPA payment account access scheme that we've developed with the together with the banks at the EPC, and which does contain a number of payment automations or which go beyond the standing order that you mentioned, which is sort of the only one available today. So there is quite some

Javier 11:08

Okay.

Ralf Ohlhausen 11:31

room in all these APIs and and and and not just actually the the compliance APIs but the extended services APIs we had Berlin group here explaining all of that in detail. So there is a lot of standardization available and it just lacks implementation. So maybe I'll ask should ask Javier on why the banks are just not going there.

Javier 11:59

Well, I do have my answer. I think there is not enough demand. It's like going to a bar. You can have very complicated cocktails, but most people ask for beer and, I don't know, a shot of whiskey.

And that's all. they do not need or most of them do not need programming what they are going to ask to the barman. And that's probably what is happening with banks that there is not enough demand from users to implement and to really make them efficient enough in terms of a scale. And that's why they do not invest because they don't have the expected return on what they have estimated the demand to be. But

that there is interest, there is that it can be done, it can. That it will grow in the future, I think it will grow, but it will go slow because people simply because they can do programmed payments, they do not do them. They do not need to do them until they get to that need. And I think that's the hard thing of open banking and the use of APIs that eventually they will be more generally used.

but we will need a long period of training and getting used to them and experiencing and doing things gradually rather than by a huge conversion. That's my view.

Lars 13:22

Yeah.

Michael Salmony 13:24

In fairness to the banks, think the neo banks are picking this topic up. mean, Revolut, one of my favorites, you can actually sweep money that excess money into stocks and savings, you can put them in special pockets and things. So we're beginning to see conditionality. before we do, there are plenty of other topics we wanted to get into and Lars already mentioned the consensus thing.

This is another one where I'm quite confused because a lot of people are saying now for the first time in history, can you get distributed consensus? Now there's for the geeks amongst us, there's the Byzantine algorithm, which was developed in 1982, I think, so over 40 years ago, which allowed distributed consensus. It was just that it was only between named and identified participants. So the change to blockchain is you can suddenly get consensus between unidentified and untrusted.

Now, in the banking sphere, there surely is KYC and AML and it's not the case. So why wasn't this already done 40 years ago? Please help us there, Lars.

Lars 14:29

So so we always joke that or well I should say I always joke that it's called a central bank and not a decentral bank, right? So in the in the monetary ecosystem, what's kind of special is that you always have when you have an asset, you always have an issuer and a holder, right? So you have someone who issues the asset, like the central bank's issuing money and the commercial banks are issuing money, and then you have holders. And in many cases, the

Michael Salmony 14:37

Thank

Lars 14:58

Payment can only be done between holders when it's been validated by the issuer. So when you're making a payment inside the same bank, it goes to the books of the bank and they're updating some ledger in their core banking system, they're debiting an account here and crediting an account there. If you're making a payment across banks, then it's the same thing happens, but also on the RTGS. So the central bank also needs to do this update. And now what this Byzantine consensus, as popularized by Bitcoin and others, allows you to do is.

You can just do that without the central entity validating that, right? So you're sort of artificially introducing friction, for example, through proof of work, in order to prevent people from doing bad things, but still be able to make those payments between two holders. And I I think this is pretty much not needed in most of finance because you always have to trust the issuer in the first place, right? So when you say

Maybe the two participants they don't trust each other. That's fair, but they trust a joint third party, which is the issuer of the instrument. If I don't trust my central bank, why would I be transacting in central bank money? If I don't trust my commercial bank, why would I be transacting in in commercial bank money? So this is, I think, one of the things where the the blockchain community has identified some issues. For example, we can discuss if there's too much friction in payments today. We can discuss if it's hard to send money across borders and so on. What

The remedy, I'm not sure if the remedy, the proposed remedy addresses all of those issues in in the best possible way. Because we also get some downsides from these consensus algorithms, and the downsides is the performance issue. no matter what you do, you will have to either compromise in performance or you have to compromise on decentralization. And I know there's a lot of people out there who say that some modern blockchain technologies they scale up much better. That's true. Bitcoin is low and there's some

Technologies that much faster, but to some degree, they always have to compromise on decentralization. If you look, for example, at Hyperledger Fabric, Hyperledger Fabric or Quotas, those are not decentralized systems because you always have a PKI in the background, so you have a root issuer of some certificates. And maybe you delegate some trust to some degree to several participants. But we always have this question when we discuss CBDC with in particular retail CBDC with central banks.

Do you really want as a central bank for commercial banks to be part of transaction validation? Why? Because it's it's central bank money. Why why does suddenly the commercial banks have any say in who can make a transaction or or not? That seems to be that seems to me a little bit strange. the most promising thing actually, so to give a bit of an upside here, is if you talk about cross border CBDC right? So you look, for example, at mBridge and so on, because then suddenly you have multiple equal partners, multiple

equal central banks participating in the system and then suddenly you don't have any more a superior party to appeal to. Maybe eventually those superior parties will emerge, maybe it's gonna be the IMF, maybe it's gonna be the BIS, maybe it's gonna be a new institution, but for now, that seems to be to me like the cross border between central banks seems to me the only use case that I've seen so far that really truly makes sense as an application for this kind of you know trustless or decentralized consensus architecture.

Ralf Ohlhausen 18:22

But if I i looking at this for me, the whole idea and purpose of the blockchain was to allow transactions between with zero trust. So essentially replacing trust with technology, which I think is a great concept. And by the way, we're one reason I believe that is that is the future, because establishing trust is a very costly thing. You need contracts, you need a lot of infrastructure, you need a lot of things, and if you can live

Lars 18:38

Yeah.

Ralf Ohlhausen 18:51

With Zero Trust, you cut a lot of cost. And yes, of course, you need more technology and maybe faster and better and whatever. But isn't i well, when I see blockchain used inside banking, it's always on a permissioned some of variant. And but th isn't that contradicting itself? So I mean, why do you need a blockchain if it's if you need permissions in addition?

Lars 19:18

That's right. Yeah, that's that's I also ask myself that question not every day, but maybe every month. but to to get to to get back on the point about Bitcoin, for example, as a public cryptocurrency. If you disagree with the government being involved in money and if you wanna make your own money where you don't need to ask anyone for permission, then of course it makes total sense. You need to use Byzantine fault tolerance, you need to to distribute that across the entire internet, you can't have KYC, you just have like arbitrary people transacting with each other.

Under that assumption, it makes total sense. But then if we're taking somehow the technology, removing that assumption, right? So we remove the assumption that we want to be in an unregulated whatever space, and we go inside the regulated financial ecosystem with banks that are issuing money and so on, then that argument starts to kind of you know decompose. So so so we we we we kind of took the

load bearing assumption of blockchain and we took it away. And now we are trying to to shoehorn it to a different ecosystem.

Michael Salmony 20:20

I love what you're saying, Lars. I mean, that makes so much sense, right? It's an idea that's been carried over from the mad crypto world and we're trying to shoehorn it into the banking world when we don't need it. I mean, to put it provocatively, with all the unkept promises, maybe the downsides in the performance, the lack of the oracle to connect to the real world, you can't put it in front of a judge, the legal value. Could one say...

We could actually do all the clever things like stable coins and CBDCs and deposit tokens without blockchain, maybe even without DLT. mean, my understanding is, MiCAR doesn't even mention blockchain, it only mentions DLT. And you could even do without DLT. You can put it on a database. And we know how to make that super efficient. And it would also serve your purpose.

Lars 20:59

Yep. Yes. Yeah.

yes, and I have two more points on this. So there's another example. That's the first point. In Germany, it's now possible to issue electronic securities. So I'm not sure if it's still already possible for stocks, but it's definitely possible for bonds. So if your company issuing a bond, then you can now do that without paper. And the the law also is agnostic towards the concrete technology. So far, everyone seems to do it on DLT.

I don't know why that is exactly, but it is what it is. And the second point I want to make is I mentioned this that the blockchain proponents they are sometimes diagnosing the correct issue, but they're sometimes not then proposing the right remedy for it. And I think there's one issue here that they're identifying correctly, which is that the financial world currently is a bunch of silos. So if you have, for example, a stablecoin.

That's typically an ERC20 contract. ERC20 is a standard in Ethereum. And then you can put multiple stable coins or compatible instruments on the same chain. And you can use just one wallet to access all of those. And you can seamlessly move money around. There's exchanges that are standardized. So you have one tether and want to change it to one circle USD and so on. That's that's super frictionless. and I think one of the things that they have done quite well is breaking up

part those silos because suddenly you can have like multiple instruments that are coexisting in the same infrastructure that are compatible and that are sort of harmonized. And this is something that I think we can do with traditional technologies, but that we're not doing or like I think we have a lot of homework to do in the traditional financial ecosystem that you know a customer can go to a bank and say, you know what, I also have a bank account with this other bank and I have a brokerage account over there and I want to issue some bonds.

Can I somehow get this within one unified API or like one w in one unified system? And I think this is just not there yet.

Michael Salmony 23:08

Okay, so what you're saying like in our discussion with APIs before, if the trad FI scene would actually get its act together, it could do this stuff totally without using blockchain and just using traditional scalable. So it's actually maybe forcing the traditional banking structures to adopt and modernize. Maybe that's the real value of this whole development.

Lars 23:31

I I mean I've been I've been I've I've gone on the record and said that the the push for blockchain is basically a push for digitization in disguise, right? So we wanna have more modern technologies, we wanna be able to do more, we wanna be able to be more flexible and so on. And blockchain sort of forces this open, this ecosystem, because suddenly everything is out in the open and maybe you have a permissioned ledger, but even on permissioned ledgers, very often the customers of that permissioned ledger can provide their own smart contracts, right? So that's typically possible.

Or well, let's say it's often possible, not not always possible. so so so in that way, if like if a bank decides to offer like JP Morgan, if they do offer decide to offer tokenized deposits to their customers, they can already do a lot of things. and this is just because they offered this on top of Ethereum that they can do all of these things. Now, if we come up with sort of like a counter proposal

how we would do such things in a traditional world with databases for example in a in a more performant fashion, I think we would have a real chance to to to gain some mind share about this. Not just market share but also mindshare.

Michael Salmony 24:39

Well.

Javier 24:41

Lars, what's your guess about the long-term future of blockchain and DLT? Are they going to change finance but finally they are not going to survive? Because when finance is transformed there will be no need of DLT and blockchains? Or do we have still room for blockchain even though finance will change dramatically with open banking APIs and all this programmability?

introduced by the backdoor.

Lars 25:13

So I think I think there will be a coexistence. and for sure the the market shares will be switching around and so on. But to give you a concrete example, I think stable coins, in particular USD stable coins, are entrenched already today. So they're probably not gonna go away within the next five years. They might survive for like we now have all of this regulation. I don't know, I mean, eventually everything will disappear, right? But I don't know if it's gonna be in twenty years or in fifty years or whatever. but one of the one of

The tasks that we have is to ensure that all of these systems can talk to each other. Because as a as a as a company, if you're holding stable coins to make payments with currencies that are more volatile, right? If you want to avoid using smaller currencies and maybe you're business based in Africa and you want to hold your USD, then probably it's gonna be easier for you to hold the stable coins than to get an American bank account. Right. So this is probably gonna be a

a a solution or a a way of transacting for a long time to come. But then the rest of the financial system needs to catch up and and needs to make sure that we're not building more silos. So may maybe as a as a kind of a side remark, I sometimes read people proposing that there's gonna be a unified ledger and all of the assets and all of the countries will gonna be on that same ledger. And it doesn't even matter if that ledger is distributed or not, I don't think this is gonna happen ever. Right? We're gonna have

Some degree of of of siloization and friction, one unified ledger that everyone agrees on it's not feasible. but the the reality is probably gonna be somewhere in the middle that there's gonna be a consolidation happening because for sure we're gonna need don't we're not gonna need 2000 different blockchains, so it's gonna consolidate for sure. And yeah, who knows what the the banking world will come up with. Maybe for now the banks are still keen on providing blockchain platforms to their customers.

maybe they're gonna experiment a little bit more until they realize that it's not all that it's made out to be, let's let's say put it politely. but yeah, e eventually there's gonna be coexistence, I'm I'm fairly sure.

Ralf Ohlhausen 27:16

Could we look at another use case which I think many will be interested in? Because you and or your company is particularly strong in offline CBDC. So now we're looking at two devices, two people who normally don't have to trust each other. so how does that play out? And is there any blockchain deep involved in what you're offering there?

Lars 27:27

Yeah.

the short answer is no, there's no blockchain involved. And I I can try to give you briefly a reason. these consensus algorithms that Michael mentioned, they always require coordination over the internet, right? So you're gonna need to put some data on a ledger and then you're gonna need to have people approving that entry to the ledger. And if you're offline, then simply you cannot do that, right? You're meeting in the middle of nowhere. for example, you just wanna get some coffee on top of a mountain hut in Bavaria, there's no reception.

But the people have two devices that that can communicate via NFC, for example, or via Bluetooth. So if they don't trust each other, we need to establish trust by other means. We cannot use online consensus algorithms. So the only thing that we can do is we can use hardware security. So you have trusted devices, basically. And the the trust in the devices comes from the manufacturer or the issuer and whatnot. I think that

Would go a little bit too far in this round. I mean happy to talk about this anytime. But I I think for this round, suffice it to say, we instead of placing the trust on the anonymous crowd that's validating a blockchain, we're putting the trust on the devices. And then you can make a transaction basically in the same trust bottle as cash, right? So you put trust in cash and people can validate that the the cash feels right, looks right, and so on.

And that's what we're trying to emulate there in in the in the offline digital currency world. And you know, the the the blockchain is nowhere to be seen there.

Michael Salmony 29:11

And also in the digital euro normal retail, there's also no blockchain, right? It's also not, it's just an account based system.

Ralf Ohlhausen 29:22

Yeah,

I don't know if if that's the same around the world though. So I think there are different approaches on CBDC. the European one, visually Euro is one way of doing it, but then there are others, of course, as we know, elsewhere. But well, I have an one more question on the programmability. or let's say an another topic that I guess people will be interested in, and that is the the difference between

Programmable payments, which we've discussed, and programmable money, which we have not discussed, and which is what many people fear or mix up. And I think it would be important to clarify what the difference is and what we are getting or what is being yeah, well what what's the plan on these two things, yeah.

Lars 30:20

So one

one example I'd like to always like to use to illustrate this is food stamps, right? So if you if you get food stamps from from from the welfare ministry or from wherever or or coupons or something like that, you can buy groceries and you need to give the cashier the food stamp, and then the cashier needs to give it to the corporate, and then corporate takes that to redeem it with the government, right? So you have this flow where

not actually money is exchanged

but some kind of coupons or vouchers and then those vouchers need to be redeemed for quote unquote real money. That is programmable money because if you're making a payment, the condition is still attached, right? So you when you when you when you move a food stamp from one person to a merchant, it's still a food stamp.

Now, conversely, if you consider programmable payments, right? So what we discussed earlier initially, you have an API that can move money around or like conditions attached to payments, then this is not the case, right? You make a payment and the conditions are gone because the payment has been made. So if I have, for example, this credit card payment that is on hold for like seven days, and then the payment is released, maybe because the delivery has been received, then the merchant immediately has quote unquote real money, doesn't need to go anywhere to redeem it.

And that is the big difference. and most of the CBDC projects around the world, they would propose to use conditional or programmable payments for the retail use cases because there you don't want that. You don't want this extra redeeming step, you don't want people to tell, okay, by the way, this money can only be used within a month or something like that. That's a no that's a no-go for retail. So so don't do that. Whereas

Smart contracts are typically programmable money, right? If you have stable coins, for example, then they're only valid within that ecosystem and you need to go elsewhere to redeem them. Or you can even like like say I don't know, you need to make an outgoing payment within seven days, or the smart contract will not let you redeem this. So so you're always bound by the conditions that have been programmed in the smart contract itself. And this is another downside, I think, of smart contracts that you're really bound by those conditions that

ha are set up. Of course they're typically transparent because you could look at the code. But in the in the retail world I think this programmable payments is just the only thing that you could reasonably do because you don't want these conditions to travel with the money itself.

Ralf Ohlhausen 32:48

Well, yes, mostly, but there are occasions where which are different. So, you know, a few years ago, COVID and whatever, there was this helicopter money thing where everyone would would get money and then as for the state, I I would put some expiry on that. So I would say, okay, well here you get five hundred Euros, but you gotta spend them before September, otherwise they're gone.

Lars 33:14

Yeah. But I think this gets very political very quickly. Like we have we have witnessed some some central banks who are engaging with this, is for also for reasons that you mentioned, like for for social or welfare purposes. But then also there's a huge backlash because of course this this problem that, you know, there's this potential that someone could put those conditions on the money is also very poorly received in public. Let's let's say it like that. So so it's a really political topic there also.

Michael Salmony 33:40

We're getting a little bit off blockchain, but that's super interesting too. mean, in India, for example, I understand they are thinking about conditional money. Farming subsidies can only be used for seeds and not going by alcohol and cigarettes. Yeah.

Javier 33:44

you

Lars 33:48

sure, yeah.

Yeah. But then

maybe also the other thing is how how would the smart contract then know? So you still need some kind of trusted party that feeds in that information saying, okay, this payment is actually valid or not.

Michael Salmony 34:04

Exactly. Okay, think we're gradually, we only touched about two, the sort of programmability and the consensus topic. There are plenty more like, is blockchain really instant? I mean, there's something about it sometimes takes several minutes and is completely indeterministic when the result comes. And we could go through all the promises of blockchain, but I think those two have probably given people a lot of flavor, at least food for thought. some...

Lars 34:29

For sure.

Michael Salmony 34:30

Some Bitcoin blockchain fanatics will not like our episode, but I hope for everybody else it's given them some food for thought to think about this topic. So Lars, you've been incredibly helpful and insightful and clear. Thank you very much. Somebody who really knows his onions and is willing also to speak out against some of the mainstream hype that is being put out there. So thanks to Lars and Ralf and Javier and thanks to everybody.

Lars 34:55

My pleasure.

Michael Salmony 34:59

Hope you enjoyed this episode, which again, wasn't easy to digest, but I think a lot of very interesting content, I hope. Okay, see you next time.