Hashing It Out
Hashing It Out

Episode 36 · 3 years ago

Hashing It Out #36: Dan Robinson - HTLCs (And why they suck)

ABOUT THIS EPISODE

We have the pleasure to present one of the more entertaining speakers at SBC19, Dan Robinson. After two talks on Hash Time Locked Contracts (HTLCs), he drops a massive bomb in with a slide deck entitled, "HTLCs (And why they suck)." Lively and entertaining, we have him step through is thoughts on HTLCs and the alternate solutions to this technique that Interleger implements. Bombastic show chocked full information and analysis!

LInks:

Entering forecast work. Welcome to hashing it out, a podcast where we talked to the tech innovators behind blocked in infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. Welcome back episode thirty six of hashing it out. I'm your host, Dr Corey Petty, and Always I'm here with Colin Cuche. Say Hello Everybody, Colin. Hello, everybody, Colin. Play Sir. Our guest today stand Robinson, currently working at paradigm and formerly at interstellar and shade, here to talk to us about HTLC's and why they may suck, along with other types of interesting technology that's currently in the pipeline for helping scale out a lot of the blockchainsistants. We're in. Dan, why don't you start by giving us an introduction as to who you are and how you got into the space? Sure, yes, so, thanks for having me on. I'm a former securities lawyers curies litigator from New York who the refugee from that career and quit to become a blockchain protocol researcher. So two and a half years ago I started a chain, but before that, so before that, I've been I've been generally interested in in Bitcoin for a few years in the theium, since the designish and white paper came out and have been sort of following that. And I want to work a chain partly in order to work on smart contract languages and Chrystography and various and various research there and ended up the past couple years of worked on I had a smart contract language that I worked on a chain called Ivy, which is a smart Kendric language for Bitcoin. I worked on some some of the sort of comminitive cryptography, but a lot of what I worked on recently relates to scaling and particularly payment channel like and plasma like solutions for scaling. So I've been where I worked at. When chain got acquired by interstellar, I worked on payment channels on stellar, this project called starlight, and while I was working on that I got familiar with the People Work on Inter Ledger, which is project I was started at ripple and got for. Are Be interested in how they were approaching build the constructing of payment network and ways in which it differed from what people sort of the most high profile payment channel network in the space, which is, which is the lightning network on Bitcoin, and that led me to really sort of like dive in on the particular question, if a very, ultimately pretty technical question, but whether the U H Shel sees in these networks. And that was and so I recently gave a talk and I've been going around just evangelizing against the use of H GLC, use was a solution used by lightning, and favor of the of the different approach, general legitation and her to talk about anyway. So then that was what I was an interstellar and then recently, about two weeks ago, I started as a research partner at Paradigm, which is an investment firm focus on cryptic currencies, and I've been working to sort of in research, doing technical diligence and sourcing on investments and just trying to keep up and follow the space and help us try to figure out which way it's going and what the next big thing is.

So first off I want to say that you were one of my top choices for first guests after Spc. I was there, I saw you talk. It was great you're passionate, your very local. Great job on that talk. You really engage the entire audience and there's tons of questions afterwards that were very insightful that people had. But was it was, overall a very good talk and it was funny because you actually had to to, I believe, talks on HTLC's right before yours and it was like that's right, htelc, it steels, and it was like hy htlc suck literally the title and like I see that title and I I knew was on my program but in like register with me that was going on and I just kind of like buses out laughing like that's bold. So yeah, so are we have not had a whole lot of discussion. We talked about atomic swaps like in a very generalistic cens on this program in the past. We've never really gotten into the guts of it and the implementations behind it. You know, that's just single Tomic swaps, multihop and that kind of thing. So I think it's really important for audience to get a sort of a primer on what HTLC's are and what a what they enable and then kind of lead into some of the you know, your knowledge of some of the implementations are out there and why they suck. Sure, yeah, absolutely so. H She'l sues our construction. That's I think you've been around for maybe a little five years and they were originally designed to support atomic cross chain swaps. So it's a way that you can do the canonical example is if someone's trading bitcoin for Lightcoin, I can send bitcoin to someone and have them send Lightcoin to me and we can structure it in such a way that my transaction all go through. If there's does so I'll only send the bitcoin if I'm also receiving lightcoin and then both those transactions succeed and it's a powerful construction and it's one that generally supports multi, you know, Cross ledger atomic transactions, even if those ledgers aren't aren't public block chain. So one. So the way that they are used in the lightning network and another payment channel networks is if they support atomic transactions where each of the ledgers are payment channels. And Payment Channel, by the way, I've nothink against, sayment channels. I think gayment channels are fantastic and it's important to note that the lightning network and these other sort of solutions are really two technologies that are sort of composed into one, and one of those is payment channels, which provide these off chain bilateral ledgers, and the other is its she'l to use to provide cross ledger atomic transactions. So it's she'll see there would allow multihop transactions on the lightning network, because the you if you've got, for example, a payment from Alice to Bob and David David Payment Channel with each other and you're also pay a channel between Bob and Charlie, then if Alice wants to pay Charlie, she has to pay pop, but only in such a way that it only goes through if Bob's payment to Charlie on their payment channel goes through. And that's how lightning provides all the hoop payments. And so they use they use a she'll s used to do this. But what I argue, the Tark of what I've been sort of just like shouting into the face of everybody in the industry that I meet to the past eight months or so, is that there's there's an easier way to do it that doesn't have some of the downsides that it's she'll sees have. So let's get into what it's how we'll sees work or audience is targeted towards engineers. Did get is dirty and in the weeds as you want. How exactly do these work and how could somebody build like a small model of an East? You'll see and they're, you know, on their Gith of account and just play with it themselves. Sure so. At Heart, and HHLC is part of a of a two phase commit protocol that sort of resembles ones that you...

...that you'd use an other areas of engineering and sort of the phases of a doing in. She'll see, I mean she'll see based thomasansaction. Is that actually your to h she'll sees one on the the bitcoin across Bitcoin lightcoin trade to you create one. H'll see on the bitcoin network in one of the lightning network, and then you complete them atopically. So the is she'll sees a contract that locks up these funds in such a way that it can be unlocked if, and only if it's the corresponding she'll see on the other chain is unlocked. And so the way you do that is, let's suppose you've got Alice. Alice has bitcoin and Bob has lightcoin. Actually, usually, usually I use Charlie is the one who has lightcoin because, as we all know, Charlie Lee dumped all is lightcoin spectacularly at the top of the mark at last year. So we'll say alice is trading her her bitcoin to Charlie and Charlie's assists trading a dumping all his lightcoin on on Alice. So what's happens first is alice creates an htlc with the bitcoin that she wants to descend. And what a NHL see looks like on the bitcoin network is actually just a bitcoin address. So if you go to if you can actually use ivy, which is the bitcoin smart conject language that I have develop a chain, if you go that Ivy Lang Dot Org, you can actually try the IV playground there and you can actually see what a lot of these contracts look like, including what a Hlc looks like, and ah'll see it's but a bitcoin smart contract looks like it's just a it's just an address. It's an address that can that can be spent from and one or more ways, and an h l see is an address that can be that can be either satisfied by one party, the recipient by providing a hash, or can be atrieved by the sender, which is another public key provide after a certain amount of time. So it's either the recipient plus this. So, I'm sorry, it's Hash pre image. So so a pre image a secret that corresponds to a hash, or the sender can get it back after a certain amount of time. And so alice locks up her bitcoin on the bitcoin network into a into an ah'll see where she's a sender. Bob Is the recipient this secret that only right now only she knows. Is I'm sorry, yeah, this is good. Right now only she knows is is the she hashes that and then she makes that the Hash in the and the HLC. And there's some time out, so let's make it forty eight hours. So she'll be able to get this back after forty eight hours, or Bob will be able to get it after. I'm sorry, Charlie will be able to get it after by providing this hash pre image. Okay, so now Charlie sees that this happens on the bitcoin network. Now Charlie doesn't know the pre image, so he had in order to get it. He has to set up the other side of the trade. For Alice. So he creates an htlt on the lightcoin network where he dumps all his lightcoin into it. There he's the sender, Charlie' the sender, Alice is the recipient. The time out is twenty four hours, as a shorter time out, and the same hash is used to lock it. So this one can be unlocked by Alice by providing the secret. Now Alice knows this secret, now that she sees that Bob Creates this, she can go to the lightcoin network, use her pre image to and her underpublicy to unlock this h she'l see and she gets all the lightcoin. In so doing, she reveals the secret, the pre image that it's needed to unlock the other, the other transaction. So the the the a she'lc over on the BITCOIN network. So Charlie can go to the BITCOIN network collect the bitcoin Bay pro by showing this this secret that he's just learned. And he has until the end of that forty eight hour period to do it. And the reason these timeouts are staggered is that Alice might wait till the very...

...last minute to actually use her secret to claim the light coin, and we need to give enough time for Charlie did. Then go use that and collect the Bitcoin it before that one times out. And finally, the reason that there's timeouts on this is that is so that if one of the parties just disappears, the other one won't be stuck. You know, they won't lose their money, though eventually be able to withdraw it and cancel the it she'll see. So that's needed this for it's a secure protocol. Yeah, so that's that's how it works when the two parties are trading on public block chains and it's a similar principle. I don't go into the switch and talking. It gets a little complicated. But if you have this in a payment channel, you do something. You do sething similar with both the both the parties, and they essentially create a payment channel inside the H L S is one of the end so you know, in a payment channel Alice can have a balance box and of a balance and then you just have the HL. He has a balance. If you exit the payment channel at this at some partic of the time, the she'll see ends up with part of that money and then if there's a problem, they can exit the whole payment channel to the main chain and then settle the h she'll see just like they would if it was done on the main chain in the first place. So that's, you know, in a very, very not going to explain really how payment channels work at that's its own discussion, but that's that's how it sh'll sees work as a sort of a a ABS general, Abstract Idea for cross ledger comic transactions. All right, so I'd like to stop real quick, and your talk also witted to this quite in detail with pictures, which may helps quite a bit. It's always fun to try and explain these things completely verbally. So if you have no idea what the ell was just said and you want to know more, I recommend you go to the show notes and watch his talk. So that way you can kind of be up to date on where we go from here and and you don't get lost in the weeds along the way. Yeah, and we can. We can put the slides there too as well. Yeah, sure, that sounds scart. And the transcripts. Yep, all right. So what's the problem with that? What's the problem with H glts? Yeah, so where should I start? The three problems that I go over in the talk, and I think these are sort of the major ones are that there is this liquidity denial of service attack with his griefing problem, and that's the one that I think is the most serious. There's a free option problem, and that's particularly when you have this ut this trade going across multiple currencies, as we did with the Bitcoin lightcoin trade, and there's just sort of an inherent complexity and difficulty of implementation. So I'll start actually with the free option problem, and this one recently he got as his sort of gone mainstream and there's a post on lightning, on the lightning Dev group about it and I think, I think people people have mostly acknowledged this is a problem with multi currency light game. So the problem here is that, remember, we had this time out of twenty four hours for Alice to claim the lightcoin in this example. No, now the Alice would we have to have this time out be love, be relatively long, because otherwise, if it's times out too early, Charlie, Charlie could potentially get both of the if you know, Alice tries to reveal this but doesn't get it included, for example, Charlie could potentially claim both of the cancel has basically and and and claimed the other one. So you need to have these time out be relatively long. But the problem there is if, if they're long, you know, this gives Alice this choice to just wait until the very last second, wait twenty three hours and fifty minutes and decide whether to complete the whole trade or cancel the whole trade. And she could make the decision based in part on whether the price of Bitcoin and Lightcoin has moved in that time period. So if the trade has become more advantageous for her, she might, you know, complete the trade, but if it's gone against her, she might cancel it. And so this is what's known in finance is an option and that there's there's real value for her from having this time period...

...that she can wait, watch the price move back and forth and decide actually whether complete this trade. And that's not necessarily necessarily something that Charlie wanted to actually agree to. He wasn't he wasn't giving her and it wasn't trying to give her an option, he was trying to do a trade. And so because of this, a long time it takes freehill sees to settle. This can be the can be sort of a problem for that and it means. It means ultimately would be hard to do an economical trade there where you wouldn't be able to we your partner, where your counterpart, you wouldn't be able to take advantage of you and take advantage that free option there. This is even worse actually than anything to this yet in the top. But is it even worse if you have the money in a payment channel, because the payment channel adds its own settlement delayed to this. So it would have to be something like two days or even more that you'd have to choose whether the Alice would have to choose whether complete or not, and so that can a lot of people think it's relative's pretty fatal for at least a at least a very, you know, well developed multi multi asset lightning network. You again, you could imagine people to sort of eating these costs, or you could imagine this reputation system kind of taking care of it, but to really have it be very robust. It's very hard to do this using a hill sees. Yeah, it didn't like the base layer to be as general as as possible, as trustless as possible, that didn't have these types of we kind of ways to gain the system. Yep, yeah, absolutely, and so that's you know, that's that's the free option problem. But people pointed out quite rightly that this isn't really much of a problem with lightning network trade. That's entirely on the BITCOIN network. Because, yes, someone can wait to less second, but why will be there incentive to? And they don't actually get an economic advantage because it's all being settled in Bitcoin. Both sides of the trader Bitcoin C again, that's that's where one of the sides of the true quot unquote trade is Alice sending to Bob and the other side is Bob sended Charlie, and so there you don't have ree option problem. But that's when we get into the other problem, one that considered more serious, which is this griefing problem. And that's a way for somebody to potentially, just denial of service, attack a huge portion of the lightning network using relatively little capital. So it's almost exactly the same as as why just describe, but the motivation here is different. So when Alice decides, if Alice waits just the whole period and either doesn't reveal the her pre image at all or we still very last minute and only reals. At the very last minute, Charlie's had now has his money stuck in this, in this, you know, his the face. She'll see he's not able to get it out until she actually completes it. And so that's so he just got it stuck for twenty four hours. And this might you know, this might be this sort of annoying. But I guess Charlie, you know, men up for this trade. But suppose this was a multihop. Lightning network came and you can do this on lightning and this is, you know, sort of the whole idea of lightning is as possible to these multihop payments where, you know, maybe it goes. Maybe take a realistic example. Suppose Alice is an account of coin base and Bob is an account of cracking and rather than having it having, you know, they don't have the channels directly with each other, even directly with with the same intermediary. Instead us to make a makes payment, it hops to coin based, to crack and and then to Bob. So if BOB doesn't reveal his pre image for the whole twenty four hours, that first twenty four hours, if he has it, that means that not only is alice is money locked up for that period, but there's a portion of the channel between coin base and crack and like if it's one bitcoin being sent, then just coin basin cracking just can't use that Bitcoin, so being for the entire twenty four hours. And this is you know, there is lightning network liquidity. It's not very cheap. All he's as if yet there is. There isn't, you know, sort of a huge supply of it and someone can for free. You know, Charlie Bob, I'm sorry, was it? Yeah, bother doesn't even pay to do is attack. They can just sort of grief the whole network by not completing this this payment, and just...

...the money's locked up in these channels along the path. And here that was just like a three hot payment. Suppose it was a twenty hot payment. They've locked up twenty times the amount of Bitcoin that they had to that they had to be locked up, have locked up for a day and so just locked up this one bitcoin in twenty different places along the entire path. And so you can really potentially cripple the network by doing an attack like this, by just by sort of locking up all the liquidity on a payment that doesn't even fleet. It's important about that aspect is that it's basically free to do so. It's not like that the attacker doesn't pay anything at a cost of doing that, because people would kind of argue that it's not spam if if it's paid for. That's a argument that the quay is quite often right exactly. And so in this case, yeah, because lightning doesn't charge any fee if the payment doesn't complete, and it would be very difficult actually to make that kind of to make charging a feed their work, because you just essentially have the charge of the unconditionally, even for payments that don't find a path or, you know, I need it's a little settle than that, but it's hard to it's hard to actually make the tack of pay in this case, certainly without making other people end up having to pay as well. So yeah, so this is this is something that someone just, you know, like Craig right or something somebody would grudge against the lightning network could do potentially in order to really make it difficult for any of anyone to any intermediaries operate on it. Now, just to be clear, for the the griefing problem, you need to have an relatively equal amount of capital. You also have to have somebody on the other side who actually decides to exchange with you. So this could possibly be mitigated by social constructs rather than just simple you know then, rather than Cryptogray, just using protocol layer stuff. Yes, yet people choose not to engage with you because you're doing this kind of stuff, then you know, then that's that's something you can implement, but in an anonymous system that's very difficult to maintain and it could also cause other sort of gaming problems. So reputation systems aren't kind of sufficient if we're trying to build something very generic and global that's trying to really quick. Yeah, absolutely, and so way it. It's true you could. You could try to do a reputation system here. What makes that difficult? In addition to the fact that it would be nice if we had a network that didn't require everybody to be to be known to everybody else, will makes euxtitionally difficult. It isn't just your immediate counterparty that can do this attack on you. If you route a payment and you're in just the middle of like a twenty half payment and the end recipient is a malicious counterparty or just somebody who you know just goes off lines that get stick aplete whatever. You don't even know them, you're just routing a payment to them, or maybe somebody like halfway down that down. The at that does is that that will still affect you. That's still end up king you for a long time. You don't you know, you don't know this party. They're not your IMMEDIAC counterparty, but you're still exposed to them. So you really have to learn not only about your the people you open channels with, but everybody along the path of every payment that you're route you're exposed to this attack from. So it's it's not it's not a kind of local trust. It's a very it requires as kind of global, global trust and global reputation system. That, I think is very is largely incompatible with maybe what we'd like a payment channel network to be structured like, or any decentralized network. I mean, it's actually incompatible in general with the philoscity behind what we're building and that we shouldn't we shouldn't depend on reputation to be trustless like that's that's the opposite of a decentralized you know, trustless network. It's exactly building trust into the network and you know, then you get questions or redemption and just you know what, if something ffs up, like how do you how do you like rectify your bad Karma as a result of that? You know. So it's just not what it's in typical to what we're trying to build here and want to build a robust protocol and robust protocols do not depend on Karma. Yeah, but so I could, I could probably argue that this is the consequence of an early implementation of something that will...

...potentially become better. And there's a few things that I could think as optimizations that would help not get rid of this problem, but minimize it. One would be like routing optimization, so like maybe enforcing something as less than optimizing the route based on cost and number of hops, so that way you minimize it. About the amount that someone could grief in that circumstance, like twenty hops is a bit ridiculous in any well connected network. And also you could do something like that. I don't know what what they call lighting network, but basically you can break up payments and route over multiple routes. So you can you can not have everything the SAR channel. But hold on. The other thing is that you don't need multiple hops in order to have this problem. In that if you want to attack clean Bas I'm just saying it, it mitigates, it minimizes the amount someone can grief. It doesn't get rid of the problem whatsoever, it just its. It lowers the potential for someone to do massive harm or as much harm based on the same amount of F funds. Yeah, yeah, yeah, I think, I think. I think. I'm also very glad you brought up the point of a breaking up a payment and in a sall pieces, because that's that's what about to get you about the interledger approach. But I also want to address when you mentioned trust. You know, I think, I think it's okay in some cases for this system to use a small amount of trust to its to it's advantage, and you can get atually get a lot more powers, and I can also going to talk about with Inter Ledger, if you do take into account the small ways in which, for example, and media channel counterparties already have to trust each other. But the idea of sort of global trust or one party that we all have to trust or everybody having to know every part of the system. I think that is a, you know, it really sort of poor feature for a system to have. So again, I think I'll when I get to when I explain how the interledger protocols method of atomic payments works. I think others trying to pind how you know it. You can see in some ways that it uses trust and but I think in ways that that are very but are very much don't lead to to that consequences of trying to do it in this kind of global reputation way that it might be needed to solve a show be a she'll see problem. Yes, I think that that's that's the that's liquidity, Denil of service, attack with a grief and attack. There's one more one more area, which is complexity. And so embedding, I mentioned before, embedding payment channels, and I'm sorry, H G'l seas inside of payment channels is kind of difficult. It's kind of complicated, relatively difficult to implement. It's she'll sees put some requirements on the Bass Ledger like that it has to support Hashlocks, has support time locks. If you've crossed Ledger Ith, she'll see is like like, I'm in payment channels that, you know, the try to cross the one ledger to another. Those both have to support the same hash function, they have to have relatively in sinc timers, clocks, the requirements. It turns out to be actually relatively, relatively difficult to try to implement the lightning network as it exists because the the specification of it is very bitcoin specific and it really involves literally the structure of these bitcoin transactions and embed these ashl to use. It's very hard to build something on a different currency that's compatible with it. And you know, I've tried on stellar and I think I found actually that's one more area where I found an allergic to actually be much easier to figure out how to use it on different substrates. So yeah, so I can, if you've any be happy to talk more about the downside, the Visio h She'lcs, or we can go, you know, straight to Damascus and talk about about what I think potentially as a solution. Let's go for the solution. Kind of curious as to what, like how you think you could you could mitigate this by getting rid of Ash She'lcs or even, yeah, differently. Yep, great, so it's it turns out I I. I love this part of by is not my idea. That came from Evan Schwartz and Stephan Thomas a ripple, who are the inventors of the INN alleged protocol, and the alleged protocol originally a hlcs. When they came up with this alternative idea, they realized that it was that it was a lot easier and and didn't have...

...these downside and so they switched in a ledger to using that. So the basic way it works, and this is I usually pose it up in the form of a riddle. So if I want to send you a dollar and have you send me a euro, let's and let's ignore. I ignore a change right right now. But suppose I want to we want to do that trade, but I want to do it in a way where you can't cheat me and I can't cheat you. So there's a problem. If one part person goes first, the other person might not complete the trade. So how do you how would you do it? So I mean, I hate to give away the answer, but it's what you're going to that is what you Yah, I said earlier, is break it up. That's right, Yep. So how would that work. I would basically break my payment into, will just say, a hundred payments. It's going to be, you know, one, one cent per dollar, and send you that weight and then a wait you to do the same thing for me and then go back and forth until we complete basically the streamed payment to each other atomically. Yep, that's that's exactly right. And See, it's it kind of expays a lot in common with the Game Theory Concept of tit for tat, because if it turns us into a repeat game where if at any point I try to cheat you by not sending you my penny, you just don't send me the next penny and at worst this be playing this game is cost me one penny. So that's that's that's the that's the essential core idea of it, and that's instead of having this big trait that we try to complete as a Blob atomically with some other trade, we just split it up into tiny payments and send it a little bit at a time. And what I love most about this, I think I think the it definitely very much mitigates the liquidity nail of service and the free option problems. But what I love most about it is the simplicity, because you can do this on any payment medium that supports chief payments. You can do it. You could do it with you can do it on chain, you can do it in payment channels, you can do it on Benmo, you can do it with thank wire transfers. Can do it by throwing pennies across the Grand Canyon. Anything where I can just make tiny payments to you and you can make tiny payment payments back to me can potentially support this protocol. And so this is it's it's similar to the way in which, like, TCP can be done over ip or can be done using like homing pigeons, are carrier pigeons. It's agnostic to the sort of the details of the lower protocol, and so that's that's that's one of my favorite things about that. An alledger and and the particular approach and the of course it also it also, like I said, address it's free option problem, because if you have a free option, it's only for a very small amount of time and for a very small amount and you can steal a little from your counterparty. But we make it a payments so small that you can you can limited, arbitre arbitrary small. You can make it one Tohi at a time and you just sort of limited to make sure that it's within the amount that you're economically willing to lose from your from this particular counterparty that you have a train you and this the protocol is, by the way, it set up so it's not that anyone along the chain of payments, if you're a multip payment, can steal from you. It's only your media counterparty and it's detectable to you. You know that they that they were the one who who cheated you in this case. So you can just close your channel with them. And finally, yes, there's there's a it sells liquidity, the nive service problem, because these payments, the tiny payments. Yeah, I think they don't lock up capital really at all when they do only a tiny amount along this path and only for a very short amount of time. Because the thing is, and again the thing about the reason that these timeouts on the hill our ledger and for stage she'll sees, were so long is that they need to be settled on the main chain, and so you need to wait for the payment channel settle the main chain chain and then you need to wait for party to be able to close that, to complete that that it sh'll see. And when you're not settling, when you're not when these are just sort of informal agreements, essentially these higher level agreements to complete these payments,...

...nothing's getting forced on the ledger and so you don't have these have these have there, you know, sort of like bound by the time that it takes actually settle this. So yeah, I think that's that's in a nutsheow. Is a lot more details, like I said in the presentation. I mean Inter religens are really big thing. It's and I think it's a really cool project and I'm just focused on a very tiny mechanism of it that I just find incredibly beautiful. I think. I think I'm a bigger fan of this bit than even even the People at an Inter Ledger, and it's like the one that I obsessed about, like the student payments. What you're talking about here is quite a broad idea and could be used on almost all current change their production right now, not only not only every every chain, and especially change that the pride protocols. But I actually just thought of there's just a lot of different of different protocols, even not blockchain. Not even you know my protocols. They can kind of take advantage of is insight, and this is something I think this is this predates, you know. There is it's an older idea, but it was one of the founded result of looking into this. There's protocols would change for exchanging information. If I want to give you a private key and you and in exchange for you giving me a private key, there's no way to do that atomically like with, you know, if you couldn't do that with like an htlc like protocol. So with the way that the sort of interligery way to do it is I give you one bit and prove that it's particular bit of my pump private key corresponding particular public key, and then you give me one bit, like I mean by a bit I mean literally a zero one. And we do this over and over and if either part of Party at boards at any point the then the other party only we know that. We know that the other party has the most. The dishonest party has one bit advantage in brute forcing the rest of it. And so again, that's it's a bit of a tangent, but I really like that's definitely different enough on the adiversity of the transfer. You need to be able, like I said, that proof involved and doing something like that for general information has to be pretty robust and efficient. Like it's nice about payments because for every payment is it's is itself just a selfinclosed payment. That's true, that that and that is true, but I think there's other areas. I mean there's interesting analogies to this too. You can do probably different things in probablistic payments anyway. But yes, I think, I think it is a it is a very robust mechanism. This is it, this particular design idea and yeah, I just have any big fan of it. All right. So for the fusters out there that they've been listening to this and say lightning is dead, is this a problem with lightning at its core, or is it something that can basically just implement this on top of its current routing framework? or H she'll sees a fundamental aspect of hell. Lightning will and can't possibly work right. so where'St of all, I want to say that, you know, I'm a big fan of lightning and I think, I think ultimately the network is going to work out, possibly quait, possibly by adopting some ideas from this. But I think you know, and I think a lot of people's doubts about lightning network are that's generally about the about the possibility of payment channel network. At least I would like to be hopeful about payment channel that works in general because I think it's a really cool design for scaling. As a question about whether it's something are fundamental to lightning, no, and it's act sally that not a lot of people know. It was that when you make a really small payment on lightning, it's already doing basically this. If I make a one setotial payment on lightning, it just wouldn't be economical to put that in a in an HHLC and try to settle it on the main chain because it she'll see, I mean it would be low the DEESC limit for an output on the on the chain and just the cost of adding that extra weight to that transaction. So you take multiple transactions to settle NHLC. I didn't have that. It's something like fifty cents. Is the is the point below which, and you know that spends on a lot of factors, but it's around fifty, the point below which you basically economically can't settle an htl see on chain, and so payment smaller than it contends on your lightning note configuration, but payment smaller than then around that amount, are just done almost exactly the way that I described, in...

...the sense that it's done. You just sort of basically make the payment, but you still sort of have this coordination among the among the whole of the parties in the route, and so they still use an hl see at a higher layer and it's a back also wait in a letter does in order to the kind of coordinate these parties along the route. But it's not it's not enforceable by the main chain and ultimately your counterparty can steel forty cents from you if they cheat you while you're doing this kind of thing. And so one way, I mean it, this turns out to be a huge palm and lightning. There's actually a relatively easy way to mitigate it, which is just to do to split payments up into these small amounts and just send them. And that can be done at a higher layer. That can be done, you know, sort of. I guess that the guess to recall the transport layer maybe where, yeah, they'd be. They would be able to keep most of the architecture of lightning network and but just sort of change the way that they send payments. I do think. I mean there's there's some other things about the way that then Orkus isign that I think are sub optimal for this kind of payment network, but I think it's something that I could definitely involve toward that if this turns out to be a big problem for them. So what about? What if I put out a bunch of like five dollar transactions and Nickeland, I'm the last forty cents of each transaction and I do this in bulk using your system? Wouldn't that be a way for me to sort of acquire a bunch of funds that I shouldn't acquire? And you know, how would you mitigate that particular problem? Right, but the way the protocol works that the promote the OB and I didn't get exactly to the deals how the multipop protocol works, but you can check out at Interlleger Dot Org. You can look at their speck and see and sort of learn more about it. The way it works ensures that the only party that you can steal from is your immediate party, the person that you have a payment channel with and if you do that it's detectable by that counterparty and so as soon as they notice you steal some amount from any payment, they can close your their channel with you and you're sort of done doing business with them. And so yes, you can exit scam your channel counterparty in this way, but it's not it's not really likely to be a very profitable thing for you. And in fact, the way lightning doesn't and this is a possible way to to do these things, is instead of instead of, well, a payment is pending, having it be held by the sender, you can amending. I know that the detail terry feels gear get a little complicated by you can structure in such a way that, instead of me being able to steal from you, it's just that either is able to grief the other. So this payment, rather than relats and transit, rather than being held by one of us that can steal open the other, it goes into the minor fees, and so that's what let me actually does. So there's no way to actually profit from this. It's just that you can sort of cause the other party to lose a little more. So that's that's one trade off. That's one particular with cent away, your choose. But yeah, the the basic idea here is that there's there isn't. They wouldn't be really a way for somebody to make a lot of money from doing this. But even if they don't make money, if they make money by closing off a competitor. So let's just say so many wants to throw up a competitors, say coin base. You know, this is where the social aspect of the world being not all Crypto, comes into play. And you want to attack coin base, you can set a bunch of five dollar transactions to coin based through or you know whatever. Not let's just say crack, and that's probably a better example. You could, you could interact with cracket. It's in some way that that's malicious. They could decide no longer to interact with you personally, but you just mpled up another anonymous account and keep doing it and you're attacking your competitor. Now I believe that it's a little harder in these particular situations due to the social aspects also having barriers to entry, but it does prevent sort of like an open platform for that kind of stuff to flur full right like kind of thing. Right. Well, so the the this is actually already a problem, it's sometimes a problem in lightning, is that one of the parties,...

...the thunder of the channel, has to pay fees. When they open a channel, someone has to have as a fund the transactions that close the channel. They've sort of put enough money in there that that those fees can be taken out. And Way worse, you know, in general, is that the party that's funding the channel, the one that's taking the risk and paying the cost, is the one that is less trusted, so the one that's maybe anonymous. And so you'd imagine that, you can imagine the same would probably be true in a network powered by Inter Ledger, is that when you have these these tiny payments, one of the parties has to go first. Right, one of the parties. There's the way the risk of the other party cheating. And if it's coin base versus you know, like anonymous five five, read it for just some some anonymous user in this channel, then most likely you'd say it's problems, let's have the user be the one to bear the risk of coin based deciding to exit scam them. So you wouldn't be able to just create a bunch of channels with with some party and steal tiny bits in them. Are Groups them for a little bit, because they wouldn't, they wouldn't open, they wouldn't with them. They open a channel with you're going to be the one funding and you'd be the one who would have to sort of have the risk of of them cheating. You to imagine, like in most channels, one of the parties is going to be the more wellknown one, the more the more trustworthy one, and the other one maybe even pseudonymously wellknown, and the other one is maybe the is maybe sort of the newcomer, and you want the newcomer to be the one who ultimately pays any risks to the channel. Those bad yeah, but we would definitely have to solve that problem on a more peer to peer basis if we're going to create sort of like the global change network for kind of idealizing at this point. That's what I'm trying to get at. That's that's possibly true. I think, I mean, I think it may well. It made it. I would already be a great improvement. If we have and we're all you have is local trust. We're all you have is, you know, I happened to trust this person because I followed on twitter or something like that. I'm only to bet that they're not going to steal a dollar for me. So I'm so I'm willing to open to channel with them. And so the you know, and I think there's a lot of other centralizing forces and in lightning, I think we we want to really want to design the system to avoid that and that's a lot of what my concern about the liquidity denial service attack. But I think ultimately, you know, you have to have some trust with your channel counter party. Anyway. You have to have the trust because the channel cost some money to open. So you're spending somebody to open it and to close it, and so I think so, I think adding this isn't really materially changing and I make in many cases you're trying to channel Kund of party might be willing to trust them for a much larger amount of so what did you think? There was a really intriguing question at the end of the at the end of your talk at SBC. It was about ramping up the payment mechanism so that it expectly grows. What were your thoughts on that? After that, after that comment, and I do see it as possibly a mechanism for mitigating some of these issues were talking about out the fractional payments and stuff like that. Right. So the big at the big issue with fractional payments, with the with these, with the streaming payers of packetized their and method, is at the payments packets. If the packets are small on the payment will take a large pay will take a long and so the you know, the the problem. If you're trying to send you do some masterment like you can maybe do ten payments a second or twenty payment a second and most and if you're only doing fifty cents, it's about ten dollars a second in throughput on this that you can send through this do this secure a channel, one way to so one of my one of my answers to that is just that I think sending extremely large payments on a payment channel that work may not be a good idea. You might as well just go to the main chain for it. That's that's the whole reason. You would just go to the main chain. You have options. You Yeah, Yep, I think I think that. I think that's right. I think really the killer use taste for payment channel that works is is mostly for a smaller payments. Another point that I make is that I think if you have a if you if you have a much larger to payment, sometimes maybe it is find a way to few seconds to that, but another is yes. So I think this was this is a great point that David Bark raised in the at...

...the after the talk was that if you have a long running relationship, a long running channel, where you've made a lot of payments over this channel and you paid a lot of fees over it, you can raise the willingness, your willingness to lose to the other party to be by some fraction of the fees that they've paid you. Right. So if you or that or of the value that you've gotten from the channel. So if you imagine that, you know, like like initially I only trust somebody for fifty cents, but then we they've sent thousands of dollars through the channel and paid, you know, paid like like, you know, tens of dollars a fee to me. If then later they grief me, they steal a dollar for me, it's and I close the channel. Ultimately I've only lost a small percentage of the lifetime value I got from that channel. So over time you develop this kind of just purr channel reputation and that allows you to slowly raise this the this and with be off. Yeah, it's that money that yes, Yep, Yep, and what's what's interesting is, you know, I said, I say slowly there, but this is it is actually if you charge, you a for a percentage of each of each payment that goes through as fees. And if you will, if you're saying, I'm willing to cap it it like I don't know, you know, five percent of the total fees that I've received over this some percentage of the fees that have received over the whole course of this channel. That worked out to would actually be an exponential growth in this in this bandwidth. So you know, the the overtime, you eventually the the spand with can get, well, can get pretty high, just the amount that you're willing to have in flight. Even if you's you only saying I'm charging five percent fees on payments that or, you know, one percent fees and payments that go through, when I'm only willing to lose five percent of the lifetime fees that I've collected on this, it's still that's still exponential growth and still can get pretty high and still, once again, like that, and in conjunction with if you're going to do large amounts of payments or a large value payments in a small amount of time, just use the main chatter every that's this is these these layer two solutions are really for either micro transactions or streamable payments in a lot of ways. I think it's right. Yeah, I think that's that's yeah, there is no one scaling solution. It's a it's a conglomeration of a bunch of different solutions used in various ways depending on what you need that payment to do. Yeah, I think that's something. I think. Yeah, other people like that should be kind of driven home a little more. There's no like one stop shop for all financial use cases. We're able to create different ways of sending money around and routing it based on how you're supposed to be interacting with that human on a financial level. That's right and I think I think one example of this. So one thing that payment channel networks in general and micropayments is a streaming, streaming packetied freiments as well, don't work for is non fungible tokens. Right. If I have a crypto kitty, there's no way for me to split the CRYPTO pitty up into into a bunch of kind of vieuses and send it to somebody pet point piece at a time. And also there's no way to have a payment channel network in a crypto pity, because a crypto kitty can only be in, could only be in, one payment channel at a time. There's no there's no liquidity there, there's no is nout. I'M gonna go ahead one up disagree. I'm not going to disagree, for I just saying that that's that's if you use in the base case as a Crypto Kitty. That is true, but composal assets could take up many types of forms and some can have partial value. That's room. So when you we're looking more towards the future, and I'm do mean very far in the future here, I could foresee things where an entire group of assets is actually sold in a bundle, but they are received in piece mail and you can get partial delivery on those particular pieces of assets, in which case it would just be a simple case of saying the entire asset is the root of a Mircle tree and I received this piece, this piece, this piece of this piece. My signer also said that they sent this piece, this piece, this piece in this piece, but this piece is missing. That could all be traced pretty pretty, pretty sure forward in the form of a composable and decomposable asset. But these that practical today? Fuck No, and I'm not really all that worried about it. But I do see a future where these...

...kind of transactions don't just apply to currency in can and just you know, footy Quinn inenagers. They can apply to actual, actual serialized assets that are stored on blockchain. But some of the twice fore, yeah, and I think I think there's I think it were other way if, if there's a token that's only valuable if you have the entire there's only one of them and it's only useful if you have the whole thing, like gay, like, I don't know, like a particular concert ticket. It might be somewhere hard to topnize that itternally that liquid. I liquard networking it because because it's not worth anything unless you have the whole thing together. But I'm not sure right. I digressed there. If maybe a better way to say that that's that's for generally true. Is You can only go down as far as what the adymicity of that asset allows for for it on front. Well, Tokens. Yeah, of Miss Adimicity is the oken. You can't break it down. I would further. I would maybe say the visibility, because we use that admisity for the other things so up in in the conversation. So I thin. So it's a physically or something like that. But I know exactly right, exactly what you're saying there, which is what are the Stut of the fundamental atom? How far can you break it down? If yeah, so just saying an FT isn't isn't isn't sufficient, like you do that the y. do believe there are the nature of entities does allow for more complex structure. Ye, and what we are rightly I have somewhat of a more philosophical movement here and it's something that call and usually used to, used to kind of ask, and a lot of our earlier shows we kind of got away from it, but it for here it seems it seems relatively appropriate, and that is these types of problems like h you'll sees, and why they may suck for these types of payment channels or payment methods and two difficulties were having with solving real scalable production level. There two solutions for cross chain payments. Do you see the future of kind of our our blockchain future going more towards like a one chain to rule them all? We're having this wide network of disparate chains in communicating with each other. So it's great question and I think one thing I say is that is that looking at right now with a Pew when we talking about Cross chain atomic transactions or a payment channel network, that that's bands across multiple chains. We thinking short of multiple economic systems, multiple, you know, these primitive blockchains. We on Bitcoin or a theory or something like that, but in the future is quite possible that one network like atherium might be actually composed of a bunch of different shards. And I think you know, if you want atomic transactions from one chard to another, there's ways to do that. That is sort of inherent and built into charting. But I think doing it the these kind of these kind of cross chain swaps of value can also be can often be really advantageous, and I think having the general the general concept of payment channels that sort of are anywhere where. My money, you know, my money is in a in a payment channel on some chain or another. I think it gives you a lot of freedom to change the architecture of just a layer one and say it's not necessarily just like a one gigantic chain. It can be a lot of different chains. That doesn't mean that they're not able to enter people on able to interact and send money to whoever they want to send money too. But I think that's to the broader point. I think that is yes, that's the Inter Ledger Vision is that you should be able to send money to somebody and it doesn't matter if you were both are using the same medium or using the same currency. That's that's just an implementation detail. And so, you know, I like right now it's kind of annoying that when I if I've got square cash and somebody else has then mo it's there's no way for me to just send square cash money to them. That arrives in their account as Ben Mo dollars or, you know, or if they're in Europe, in your might, I want to arrive as euros. It's relatively hard to have a to even even today, to send payment in that way. So yeah, so I think that's that's sort of what the potential that Internagor has. It's just abstract all this way attract away how I'm holding my money, how you're holding your money, and you can just tell me this is where I hold my money,...

...this is how I hold it, is what I want to receive, and then just like send it and everything all the interrities or intermediaries in between through the work of Trans Translating what I have into what they want to receive. Yeah, so I do. I do think that we will ultimate have some kind of multi blockchain future, even if it's all under some homogenous system. So yes, I think that's important. So that's the key phrase you put there at the end, and so I'm going to I have a soapbox, got damn it, and I'm going to use it. So I still I'm still in the one world. Block chain, the just the evolution of the world in the way it goes. I don't see us. We don't have multiple internets, you know what I mean, and what we're creating is sort of a net of value. We might have individualized like things, but there's one protocol which we all kind of adopted as our means of transferring packets of data around. As we're going to do this. I believe we're going to the same thing with value, and I think it'll be very light and thin and nobody will have any problems at accepting it is the center of truth. Everything you're talking about to me sounds better suited for layer two, and that, yeah, okay, you can hold it in your own ledger which is very private and lockdown and only certain people can see it in super encrypted and there's likely one way you can get to it, and that's because your company enables it or this particular government organization controls it. But ultimately it inherits its truth value from one single source of truth. And I believe, like just the way evolution of society works, we all eventually adopt a sort of link with Franca for trade, and I see blockchain is being another type or not just blotching, just decentralized truth mechanisms, as being sort of another language, that is, a language which computer speak between each other in order so they could trust each other. And I believe we're going to build a tower of babble for that, and I think everything you're talking about yes, they're probably will be interchain protocols, but their routing mechanism will probably be some sort of main center of truth. Well, so I think what you just describe it is there's rights. Is One way that that's it all works out that way, and it's because it's all on one root blockchain on which we all have consensus. But another is, I think that the that you use the Internet is as an Allergen. I think actually the Inter Ledger itself is is maybe more like that. I've sort of this one thing that everybody is using, and when it does, it connects all of these different networks, or the the Internet connected a bunch of what were then header adgenous computer networks using one protocol by which anyone could then could send back a communicate with anyone else. And I do think there's a possibility that people end up storing money in a bunch of different ways and because some of the could be in thanks, of it could be on blockchains, of it could be on you faster block chains would be more fully featured ones. So I think I probably do disagree with you on that then, because from a US perspective this would be like what intelleger gives you is essentially ability to abstract away all those differences. So would actually potentially gives give us a lot more room for for difference, in a room for diversity and in what the Bass layer is. Because ultimately, if I want to transact with you, I if I'm using an interledger, I don't have to speak the same language as you. So, thinking with another technological, more fantastical analogy, if we all had universal translators, it's quite possible that the spread of English as the only language might actually reverse and people would because it would be might be much lower cost for people to Commun agree a cross languages. We might actually destroy that tower of babble and then scattering, you know, the to the winds and saying that the you know, everyone can speak their own language because when they need to come together, we can use these translators and they can all talk to each other. That's a change. That's a change in the in the what you're considering base right. When you when you start with a one block chain to rule them all framework, you're considering the blockchain, the the the ultimate base layer on what people agree on and the multi blockchain world. It's it's switched it's the exchange...

...protocol which becomes more base than the actual leisure itself. I think that's right. Yeah, and I understand that perspective. But My, my, my, when I look at what the world needs and what it really wants, is it wants an oracle of what is true and what is not true. And when you break things up at a different ledgers, you have to introduce an element of I trust this ledger and I don't think that we're really wants that. I think that we've desperately been searching for this one Oracle of truth. This, this is this is where our information is recorded, this is where things are true, and when you do an exchange protocol, you have to believe that the other chain is adhering to a set of rules that you consider valid enough to do exchange and that audit process is taxing and costly and unnecessary, and I believe you could cut all that out if we just have one root, root center of truth which dictates all of this, and then everything you're talking about makes perfect sense to me. But as layer too, from a risk perspective, I think that's a that's a it's a harsh way to move forward, because you have to get that single source correct and you can yeahs appropriately if that. I'm really fine with that. Everybody and everybody has to agree on it, but I believe that that's a natural evolutionary process that we've probably seen society. I mean that people are just going to see the benefits outweigh the cost of trying to determine whether or not, you know, the the farm a chain is accurate. You know, I mean, I'm you know, I'm Ig not tak on a general question, but I think, I definitely do think I could play out the other way because what you just said they're about I need to actually verify what's true. You know, if I'm doing exchange with IM, but I need to verify their late leasure. That's not actually true. I mean, if I want to send money to somebody, I don't actually care about whether, from my view, my point of view, they receive it. All I care about is whether they're happy right where, they received what they wanted to receive, and so it's a very subjective thing. If I'm doing business with somebody, I don't really care if we all agree on something. All I care about is agreeing on something with the person that I'm doing business with, and I think this. You know, the economy really runs in this kind of on this kind of local trust and the the problem of sort of this global of globally connecting these these different pieces of local trust into something where where we can set we can actually meaningfully transact with people who are who have different sources of truth from us. That's where these protocols become, become very useful. So here, I think. I think that's I see that being potentially where it works out. I think it's I think there's some analogies here to the Internet, but that you know that that could be a whole other discussion. I definitely encourage you, if you haven't yet, to have to avenge for its or spon Thomas on to talk more about the broader inner ledger vision. Yeah, that they also city. I can think a lot more about that. That would be alto and I've make a me sure make one more point in that. You know, the way people value things is becomes very subjective at that point too, and I think people don't like that either and it's very it doesn't help automation at all. You know, values and values inherently subjectives, not that's that's they're not find this not by necessity. That's what I believe, is that I think that we are striving towards more economical delibrium. That's always been kind of like the Holy Grail, and a lot of that is just in determining what the fuck is value. Fare well, we could go balls deep into getting incredibly philosophical right now, or we could wrap it up because it's been about an hour. Are there any questions that you hoped we would have asked you and we didn't? No, I mean, I think we got to got to a lot of them. The one thing I want to I want to say, because I want to be fare to that critics, is that's is there's one other downside of the inner ledger approach that I forgot to mention, which is that you can sometimes have payments partially complete as possible, that I'm trying to send five dollars somebody and liquidity dries up in the middle of this payment and I only end up sending two dollars. Fifty and some people have said a lot of lightning people. For some reason this just...

...really stresses them out, this possibility of a payment partially completing personally, I think it's I think, you know, there's a lot of ways to fix that. You can, we can find another path, you can refund it, you can just go settle on the main chain. But I also think you can never liability built on top of that. It's just the same way where the Internet works now, like if you drop packets, you have like the reliability layers built on top. That's right, and I think, I think if you have a liquid enough network, especially because you know nobody's like griefing the whole thing with hhlt's, if you've a liquid enough network, it really shouldn't be a problem to try to find a way to complete or eath on that. But yes, but it is. It is. It is sort of a downside and it does require any thing. Really. We architecting a lot of how we think about these payments. So we're not trying to worship out amissity as this as a fall title. All right, just like the way the internetworks now, stream everything. Yeah, yes, stick around a little bit and we'll talk about tocial guests that we could pubbly thinks we're coming on the show. Shit. Thank you for coming on and for the guests who are still listening and still with us. Thank you for joining us. If you liked this, please hit subscribe with the like button. Share with your friends on twitter. You can find me at core petty on Twitter and calling it at Colin Cuche, C L I in cus see. And Dan, what's your twitter name? Oh Yeah, I'm at Dan Robinson on twitter. There you go. That's to go side Dan and give them all your hate speech and we'll tell them how much I'd love to do it. No hate speech, guys. Come on, come on, there's Corey. That's gonna be your sound bite, Dude. All right, that was great, man,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (133)