TFTC: A Bitcoin Podcast - #137: Chris Stewart & Nadav Kohen

Episode Date: March 4, 2020

Join Marty as he sits down with Chris Stewart and Nadav Kohen from Suredbits to discuss: - Dairy farming + life in Iowa - The inception of Suredbits - Building products to take Bitcoin to the masses - The Lightning Network - Key management on the Lightning Network - Node fallbacks + redundancy - Discreet Log Contracts - Oracles - BitDevs Chicago - much more Follow Chris on Twitter Follow Nadav on Twitter Check out Suredbits Peep the DLC blog series Shoutout to this week's sponsors. Cash App. Start #stackingsats today. Use the promo code: "stackingsats" to receive $10 and contribute $10 to OWLS Lacrosse you download the app.

Well, hey there, freaks. It's your boy Marty Bent here to introduce this week's episode of Tales from the Crypt. I had the immense pleasure of sitting down with two gentlemen from the Shored Bits team. If you freaks remember last week's Rabbit Hole Recap, Matt and I talked about the discrete log contracts demo that they put out. And if you remember correctly, we did a pretty poor job of describing what they were building. So they were in town this week, headed to BitDevs tonight. and they swung by the studio last night. We had some coffee, some whiskey, some water, and we discussed all their building at Short Bits.

It's a pretty robust product suite that they're working on there. Really cool backstory, too, on how Short Bits came to be. Long episode, over two hours. I think you guys are really going to like this. I learned more in this episode than I have in quite a while on this podcast. It was a very enjoyable conversation for me. I think you guys are going to like it, too. This episode of Tales from the Crypt is brought to you by the Cash App.

You freaks already know all about them. And if you don't, let me tell you about them, all right? They're doing many things to help you save money, to help you stack sats, and now to help you stack stocks, all right? First, they got their boost program. You sign up for the Cash App, use the code stacking sats, then you get your boost card. You get a little personalized debit card, accept it anywhere Visa's accepted, and they have their partner boost. You initiate your partner merchant boost, and you go spend some money there, whether it be your local coffee shop. There's a $5 off any grocery store boost hovering around there every once in a while.

They've got Nike, Chipotle, DoorDash, a bunch of other. They're always cycling through us. Make sure you're checking your boost. When you go to the merchant with your boost on, you use your boost card, you save some money. They're helping you save money that way. They're helping you stack sats. They're helping you use one of the best saving technologies to ever exist, Bitcoin. You can stack sats, send sats, receive sats, sell sats if you so please on the app.

You can do that. And then on top of that, they're helping you stack slivers of stocks. If you want to get into the stock market, probably not the best week. Maybe if you're buying dips, if you think this dip is going to go up, this is not financial advice. This is an ad read. Cash App is letting you invest in slivers of stocks. So if your favorite stock is a little too expensive, you can buy as little as $1. Because there's no 4-5 day waiting period on the Cash App, you can start investing today.

Cash App Investing is a subsidiary of Square and member SIPC. All right, freaks, use the code STACKINGSATS when you download the app. You're going to get $10, and $10 is going to go to our friends, Owls Lacrosse. That's owls with an O. Owls Lacrosse. Very good organization out of Chicago. Nothing to do with owls lacrosse. Let's come back.

Enjoy this episode. Again, Chris and Dav, a beast out there. short bits is one of the most underrated companies in the space in my opinion building dope shit they're helping educate bitcoiners uh and they helped educate me last night so here's our conversation you've had a dynamic where money's become freer than free if you talk about a fed just gone nuts all all the central banks going nuts so it's all acting like safe haven i believe that in a world where central bankers are tripping over themselves to devalue their currency bitcoin wins in the world of fiat currencies bitcoin is the victor i mean that's part of

the bull case for bitcoin if you're not paying attention you probably should be what is up freaks welcome back to tales from the crypt it's your boy marty bent here On a rainy Tuesday afternoon. It's Tuesday. It's Tuesday. I'm losing track of my days here, boys. Very excited for this. If you freaks listen to Rabbit Hole Recap last week,

I'm going to post this tomorrow, so it is last week at this point. We talked about short bits and their experimentation with discrete log contracts, particularly their prototype and demo. Is that correct? Yeah. They launched.

uh matt and i me particularly did a pretty terrible job of describing it so uh the short bit team is in new york this week so figured we'd sit down and actually get some good information here i'd like to introduce you freaks to chris stewart and adab going hey welcome to iowa boys yes sir chris was just describing to me how he grew up on a dairy farm let's dive into that what was that like how'd you go from dairy farming to bitcoin uh there's a there's a very direct relationship between dairy farming and bitcoin no um uh you know i grew up you know you don't get to pick where you're born at and i was fortunate enough to be born on a dairy farm and definitely have seen you know different aspects of life compared to most people that i interact

with uh i think it's here in the tech scene i think it's a lot different than a philly boy the philly experience yeah um you know you grow up and just things are different like you know as we were talking about before it's like you're kind of out in you know very rural parts of america you know you got your land which is you know kind of held as sacred it's our land what are you doing on our land like this is you know we can kind of do whatever we want with our land um and you know you also have this like independent streak when you live on a farm too like you actually you know need to do you you aren't reliant really on other people um you don't have anyone to look over to it's like can you please do that it's like no you've

got to do it at the end of the day and take responsibility for you know things that happen on the farm what uh what was what's it like milking cows how many cows did you guys oh man we're getting into the do you have your family still has a farm uh no so actually uh i like to i like to joke about this but uh i went to college in 2010 and uh my dad actually sold the cows in 2011 after his best employee left the farm so yeah so he he just does crop farming now and uh he he doesn't have uh any animals anymore any uh dairy cows so um but milking a cow is quite the experience yeah everybody should do it at least once i think uh now we're talking i want to own a farm one day with cows and cattle particularly yeah beef cows or dairy cows i'm hoping beef

much less work I need to learn how to butcher I need to get okay with blood first yeah that's uh Chris you haven't talked about the smell oh yeah the smells are wonderful it's uh something you become

accustomed to I guess is probably the best way you know what's the most shocking thing you grow up on a dairy farm and you're just basically used to it and then you go back and it's like oh my god Jesus Christ how did I do this man this is pungent all right before we get to your transition from dairy farming to engineering and particularly

engineering for bitcoin to dove what was your iowa experience yeah i had a very different iowa experience i grew up in iowa city which is a college town as chris knows because he went to college there um and uh both of my parents had graduate degrees and worked in the sciences my dad was a chemist my mom does genome sequencing and so I they they actually both grew up in agricultural places though as well like on farms doing stuff so I was still treated with a lot of independence unlike a lot of people in in Iowa City well I don't know I don't want to generalize for everyone in Iowa City but I felt like I uh didn't have most of the normal like cultural restrictions of like be home by you know some reasonable hour etc they let you live yeah did

you uh wind up going to Iowa too I did yeah oh yeah all right so how did you guys find bitcoin we'll start with you Chris uh well the the bowels of the internet of course um no so I was doing a internship in 2013 at an insurance company and uh like most other people came across it on the internet the price had gone up to like i think 200 bucks at the time it's like oh what's what's this and like you know read about it for like maybe a day or two it's like i don't understand this and it sounds like a ponzi scheme uh so like threw it away then like you know november of 2013 came back around like oh this shit's still popping like still happening and uh you know The price went up to $1,000, and I was getting a math and CS degree at the time.

I'm like, well, I can actually maybe see if this is totally just a scam or if it's a real thing. I started looking deeper into what the ideas behind Bitcoin were, the story behind it with Satoshi Nakamoto, how this code base is open source. You can actually audit this stuff and kind of just kept reading, kept reading, kept reading. and uh now i find myself here and what's scary to say is 2020 uh still working on bitcoin i guess so uh seven years uh i guess it goes by that quick really quick that's about like when i found it yeah what were you we were young men back when we found bitcoin now we're old curmudgeons what uh what kind of software engineering were you doing before you found bitcoin

So I worked at an insurance company, just basic like Java stuff. The insurance company was State Farm, huge behemoth of an insurance company, and I was just a small car machine. Jake from State Farm. Jake, yeah, sharing about those LOCs. Yeah, so nothing too interesting there, but the backstory of Shredbits actually kind of came out of that. it was the winter of wait winter of 2014 spring of 2015 I pitched a startup accelerator in

California called Boost VC and the first idea behind Shredbits was becoming an insurance company for Bitcoin so exchanges you know they have all these Bitcoin on their balance sheet it'd be really great if they could have insurance policies for that that was the original idea coming from an insurance company he's like oh yeah this like makes sense um found out that the regulatory requirements for being an insurance company and the capital requirements for being an insurance company are extremely steep and that is still kind of not a solved problem in this space so um pivoted sure bits after that went and focused back to kind of my technical roots which is kind of i guess what we're here today talking about does that make sure bits make a lot more sense

now yes yeah so nadav how did you find bitcoin and end up at short bits uh yeah so those are actually the same thing those two questions and so I was at the University of Iowa doing math computer science and I was doing some research with a professor in the CS department who had had Chris and who Chris keeps up with and I was graduating somewhat abruptly I made the decision to graduate when I did and kind of just applying to various jobs and the professor who was overseeing my work came up to me and was like hey what are your plans you know just kind of conversational and then he mentioned that you know he had a past student who was like looking for you know good software engineers I could put you in touch and I'm like well my only requirement is that I want

to live in boulder so if that's a possibility i'm i'm down for it and so i met chris at like an iowa city java house just like he was wearing like a vikings t-shirt it was super chill and um uh yeah we just chatted uh about various cs things and i i read the bitcoin white paper in preparation for this uh meeting slash interview did you think it was a scam too i guess i mean it's not that i hadn't heard of bitcoin beforehand i just hadn't really given it any thought i uh didn't have too many financial or business inclinations prior to this my plan had been to get a phd in math since i was like a freshman in high school so uh kind of just happened and then i met chris and took took the job at sherd bits and began

learning what bitcoin was after that there's a lot of hard math in bitcoin did you find um not a cryptography side don't get them started certainly there is uh yeah it's not really where you start though i i feel like um but uh there's a bitcoin's what you make of it i guess so i like that certainly i've i've found myself in a place where i'm reading plenty of math papers yeah it seems like you're building dope shit too i really like the uh discrete log contracts demo that you put out last week obviously wrote about it talked about a little bit but before we get to that let's talk about short bits pivoted away from an insurance company and you guys got a sick suite of products it looks like and your ethos seems to be that you want bitcoin to succeed you think

lightning is a good way to make that happening you're creating uh implementations libraries and messing around with uh i don't want to call it futuristic tech but tech that is not widespread within bitcoin yet well um i think uh you know our big bet is on lightning and uh you know our kind of core product what i feel like is data for uh payments over lightning for data um i'm a believer in anything that's kind of digitally native in exchange for cryptocurrency generally um like a machine payable web type thing exactly exactly so like and then thinking about okay what what kinds of data have inherent value to them. Financial data is one of those things

that has inherent value to it as we see in the traditional finance space. People pay a lot of money for data, certain sets of data anyway. And I think where we're gonna see the space go to is the same thing with crypto. Exchanges right now get away a lot of their data for free. My pitch to exchanges is you should be setting up

a lightning paywall for this stuff and charging for that as well and an additional revenue stream. I'm a believer in the long term we're going to see competition between exchanges really heat up, so you're going to have to look for other sources of revenue. But in the short term,

like where we're at with Lightning is we just need to get more Lightning adoption. And so like whatever we can do to kind of facilitate more Lightning adoption is what we're interested in doing. So kind of over the last couple months, or maybe up to a year at this point, we've been writing a lot about like

how do you operate Lightning at scale like what are the unique problems that uh you know big businesses have on lightning have on lightning that maybe if you're just kind of a hobbyist operator that you uh wouldn't run into so that's another kind of active area of research that um we've been working on uh over at sure bits and we've written a blog post series and i'll be talking about that at bit doves uh tomorrow night as well, so. Dope, and Lightning's what, two years old now? Are you happy with its progress up to this point?

I mean, I think one of the biggest milestones in 2019, I think this happened in 2019, was Bitfinex spinning up a Lightning node. I firmly, or I don't think it's a controversial point to say that most commerce that happens on cryptocurrency networks today, it flows through exchanges. So if you really wanna see any product adopted,

you need to get the exchanges on board for that. So we wanna see Lightning adopted widely as a technology. We kind of have our business model riding on that, so we need to play a part in that ecosystem of getting exchange operators comfortable with the security model of this stuff, like how liquidity flows around the Lightning network, the privacy stuff, the regulation stuff,

all these kind of questions that are still kind of open questions in my opinion yeah no it's still coming together like we were talking to jack mallers a few weeks ago and he was just explaining like the like and the way i described what he was explaining is like we're still discovering the edges of this network and how it works and best practices and he was describing how maybe the way he made olympus wasn't wasn't the best for there was trade-offs you make right yeah it was a privacy and um taxability yeah yeah i mean i think uh me and jack in general agree a lot on the financial use cases of lightning um in kind of like the speculative speculation sense uh i think that's

going to be an error i think that's a pretty uncontroversial area that lightning is going to be successful in um at least payment channel technology like what i find when i talk to people about lightning is they often think i was trying to get a well-formulated i thought here like coming into this because it's like a really nuanced thing it's like almost when every blockchain technology thing like people just think of it as like technology but with the lightning network they think of it as like a network whereas i almost think with the lightning network you should be also just be thinking of the fundamental technology it is which is like instantly settled transactions with like little to no counterparty risk um and keyword it or the key

point there is it's just faster than everything else yeah that's i mean like point blank just say that faster clearing of payment bitcoin payments like that is great no 10 minutes we're talking seconds i'm a happy lightning user we said like i've said this many times on this podcast like i set up our store node um for the tftc merch store and our shout outs and all that on our website our website store our website node excuse me it's worked flawlessly like i just opened a couple i mean we're not like a huge economic actor in the space we don't have crazy amount of money flowing through our site change that guys go to tftc.com.io or.io.io.com's taken um help marty stack those milisats the milisats yeah it's a we got the dime bag you guys it's not quite milisats a lot more

but um it's actually crazy uh 91 of our transactions through the site have been via lightning wow that's impressive uh but it makes up like uh 23 of the value or something that's interesting yeah maybe even less than that i pulled those up top my head i have the spreadsheet somewhere but um people are using it people like experiment with the dime bag particularly but again going back to my original point like it's just worked for me but even with that being said it has its pain points right so what do you think uh is most pressing for the lightning network to solve in the short to medium term so i think again i want to draw distinctions between like smaller node operators in like large entities would be operating on lightning networks i do

feel like there are different problems for those sets of people um what we've written about a lot over this past year is you know if you're in exchange using lightning custody funds on the behalf of you know other users security is number one story right yeah and you got just launched a product that helps with redundancy so that's another thing but i i just want to um kind of We've talked specifically on the private key management stuff here. So Lightning is a little bit different than a traditional Bitcoin hot wallet in the sense that why I bring this up is exchange operators, they're comfortable with the idea of a hot wallet. They understand they have these collection of keys. These keys control UTXOs and you got to keep the keys secure.

You've got to make sure that the addresses that your customers input and flow through your system don't get changed somehow on the way to your actual signing logic. Those code paths are very important. With Lightning, instead of having to worry about this one key, you have to worry about six different keys. So some of those keys can be hot keys. Some of those keys must be hot keys. Some of those keys can be cold wallet keys.

and like this is something that I think you know before we wrote about it initially hadn't really been considered before I know there's a couple guys out in San Francisco now that are I think actively working on it Ken Sedgwick and Dev Random are their names but

that security story just from handling funds on Lightning if you're going to be dealing with I mean I think hundreds to thousands of Bitcoin on a Lightning node someday like you need to have that story pinned down and you need to get these professional security professionals that operated these exchanges comfortable with that story so we wrote a blog post probably in the June time frame of

last year just iterated or looking through these different keys explaining what the key is for what the purpose is and then what can happen if that key is compromised like what funds can be stolen from your lightning node if they get a hold of this key but they didn't maybe compromise another key like what's the doomsday scenario in this channel so just really thorough like

thinking through yeah these different scenarios and trying to promulgate that information to the wider community I didn't know there were six keys I had to protect keys and secrets yeah I mean I think the commitment per commitment secret

yeah so let's describe the keys what Okay. Here we go. Let's see if I can remember them off the top of my head. So we got the... Pop quiz. Pop quiz. I guess I did lead myself into it.

We got the funding private key, which just means lightning channels are in a multi-sig output. Marty, if you and me are in a lightning channel, you would control one of those private keys. I would control the other private key. It says HTLC. No. Those are different keys. That is the collateral that's backing our lightning channel. So, like, let's say we opened a channel.

So, we're talking about the opening and closing function. Exactly. So, like, let's say I want to open a channel with you or the TFTC store. I put up one Bitcoin in the channel because I'm going to be sending you a lot of sats. Wumbo. And that would be the funding private key is the thing that controls that two of two output from my side. And you would also have one. The next key is the two remote key.

So this is like getting into, I want to try and not hopefully get too far in the weeds here. We'll see how I get as far in the weeds as you need to see how I do. So, and check him on the blog post. Cause that's what, that should be your source of truth. Not this podcast on a Tuesday after waking up at three in the morning. But so, okay. So there's the two remote key. So what this means is if you go to the chain with your commitment transaction, I can take

that money immediately and send my rightfully earned money back to myself so that is the key that controls that output on your commitment transaction so lightning's hard to explain because there's these ideas of these asymmetric commitment transactions that are going on uh symmetric yeah um so uh the the next key is the to local key so on my commitment transaction output with that represent my rightfully earned bitcoin uh the two local key is how you claim money uh after the time lock expires when i close out a lightning channel okay so that's three there is the htlc base point secret which is what you were kind of referring to earlier when one of these htlcs is flying around the network we're transferring funds we get caught in this weird

state where an htlc is hanging off a commitment transaction and one of us go to the chain you use that private key to claim funds in the htlc itself so that can be a and that can be a cold key the two local key can be cold and the two remote key can be cold right so the three keys we've talked about actually can be these are keys you send funds to not spend yeah so the funding private key must be hot. The too local, too remote HTLC base point secret keys can be cold and, okay, what

per commitment secret, that is the thing that enforces the revocation penalty mechanism. Chris just had his eyes closed. He's visualizing. I am visualizing. I have a talk about this in Germany, too. I'm like, he's just picturing Schroedewitz.com.

I know, exactly. Photographic memory, don't. No. That's the thing that enforces the penalty mechanism That has to be hot. It's not a private key per se, but it kind of functions as one. And what is the last one I am forgetting? Too local, too remote, HTLC-based. Is there a timeout one I'm forgetting?

Oh, man. Well, this is what happens when you do it live and don't rehearse. While you're thinking of that, Dav, I think that comment you made is, so is it split, the cold, hot keys split between spending and sending? So all of the cold keys only receive funds because anytime you need to spend funds from somewhere, you need to sign with those keys. Now, some of the hot keys do other things too,

and this is why I kind of said keys and secrets is not all of them are keys in the traditional sense. Some of them are secrets. So, for example, the per-commitment secret is you generate for every single update of your commitment transaction whether that's adding one HDLC or adding 10 or reverting one or whatever you're doing every time you update your commitment transaction you generate a new per commitment secret and at all times you have one per commitment secret that only you know and your counterparty knows all of your previous per commitment secrets

and part of the update mechanism is you reveal it to the counterparty so obviously once it's been revealed it's not private information anymore it doesn't matter if that gets leaked so this is kind of like a hot temporary key that uh only lives for the length of the next update and um just it's the last key to is that what you mix with the per commitment secret in the penalty scheme but now i for the life of me i can't remember what it's yeah it's probably one of those it's like delayed tricky secrets payment base point or something uh you're right you're Right, yeah, there's another base point. I can't remember.

Yeah, I mean, so, like, this is, like, part of the problem with Lightning is, like, if you go to, you know, serious economic entities with this stuff and just being like, oh, hey, there's, like, six private keys. Like, wait, which ones can be cold? Which ones can be hot? We do study this before we talk to them so that we, like, actually have it prepared. Yeah, and, like, so, like, this is, like, where we're trying to move the ball forward on this conversation of, like, how do we understand the security model of Lightning? Like, if you want to put, you know, funds, like, serious amounts of funds in these things, like, how do we get you comfortable with that? And does comfort come with abstracting that away? Well, I mean...

Can you abstract that away in a GUI or something like that? Well, for these security professionals that I guess we kind of have in mind, it's they very much want to be custodying their own funds. They do have, like, say, if you're a Coinbase and you work on the security team there, you need to understand this stuff. like any anything that is uh you you don't want to be outsourcing to a third party unless you've decided to wholesale just bit go take my funds or whatever yeah but is there something like i'm thinking of caravan that on chain drop for multi-sig and that software i still control that whole process but it's just made a lot easier so um i would imagine that lightning operates at a speed that maybe isn't conducive to that because again like speed kills in some

senses with security stuff right like you're moving money very quickly you need these keys accessible very quickly to be able to update your lightning transactions which is at odds with what common security practices in the space are of i want to move slowly keep my keys as far away from the internet as possible um have you know only a little bit of money online um so there there is kind of this uh ethos friction yeah yeah there's this kind of trade-off here and yeah again it's not that exchanges can't do this i mean they they already operate wallets with thousands of bitcoin in them already it's just a matter of educating explaining like getting them comfortable with this stuff and uh just like uh we had to do you know in the 2012 2013 era of like talking about

how do you operate a hot wallet properly yeah it's a big learning curve man yeah i mean like and it's changing all the time yeah i mean and this is something we again like think that is very important for like widespread lightning adoption and this is table stakes like this is this is you know we put this in our lightning 101 blogs post series for exchanges because like that's the first question you should be asking if you're a responsible custodian of people's funds it's like how do we safely operate this stuff and minimize as much counterparty risk as possible so all right so answer that question for us i mean i i think it's uh so you know our kind of plan of attack is to attempt to reduce the problem down to or reduce the number of keys first off

that have to be hot like that's just yeah that makes things a lot simpler when you have to reason about less keys and then with the keys that must be hot like you we need to try and fit that into their existing wallet signing flow infrastructure uh so uh they can hopefully just leverage security practices that they have already with key handling stuff so um is there monetary thresholds, too, that come into play? I'm not sure what you mean by that. How many sats do you hold in a particular? Well, this is, so, yeah.

I mean, there, of course, is the consideration of, you know, you don't want an excess amount of capital on your Lightning node, just, again, following good security hygiene practices of, you know, don't keep money on a hot wallet that you don't need to keep money on a hot wallet. With trade flows that you see through exchanges, I don't know what that number is.

And this is just, I mean, for all of us, it's picking a number out of a hat at this point because we don't really have a whole lot to go off of in terms of data so far. I think we'll see large capital transfers between exchanges by traders looking to arbitrage between exchanges. I also don't think those things are going to be happening on the public Lightning network. I think those will probably be private channels between exchanges, maybe with some liquidity, private liquidity providers put in there.

But again, this is all stuff that, you know, we're kind of all speculating on at this point because only Bitfinex has adopted Lightning as a withdrawal and deposit mechanism so far, at least out of the big exchanges. Yeah, no, and I completely agree with that. like the arbing between exchanges the uh utility that lightning provides with that use case particularly will drive people to adopt this i think yeah i mean i you know like we wrote um see we wrote a blog post a couple weeks ago about like just basically how people transfer capital and crypto right now and it's like if you have fiat currency you got the silver gate exchange network if you've got uh if you've got stable coins you can you know transfer like gemini dollar Coinbase, USDC, Tether. But those coin transfers are limited by how fast the underlying blockchain

can confirm funds. So if you're an ERC20 token, you still need to be confirmed on the Ethereum chain. If you're on the Bitcoin blockchain, you still need to be confirmed on the Bitcoin blockchain. So we're roughly talking tens of minutes here. A step in the right direction is Liquid with what Blockstream's offering. But that's still a minute, right? That's still a minute, right? Exactly. And that's, I mean, again, it's an order of magnitude improvement,

but we can still go another order of magnitude improvement with Lightning. So Liquid is still interesting in the fact that you can do stable coins on top of Liquid with Lightning is my understanding. And you can probably also have

kind of like a simpler security model for transactions where a minute is okay but obviously if you're trying to like do arb that's just not gonna be uh really i mean it's a long time yeah i mean if everybody else can transfer a second and you're transferring in a minute like it's if you are latency sensitive i guess sometimes you aren't yeah um but if you're not a right tool for the right certainly seems like uh there's some cases where that would definitely be the way to go yeah no it's again like i think it's inevitable just because the utility provided um it's uh like it's so big that people will figure out a way to make it happen

yeah i mean and this is you know being in chicago it's you know go talk to some trading firms that operate in the crypto space and say like you know try and make both ends of the market meet you know talk to the exchanges be like hey this is what traders can do with this go talk to the traders but okay this is what you can do with this too um trying to sell that i feel like a lot of people you know there's a lot of technology in this space and it's hard to stand out because i think a lot of people can't tell what's vaporware and what's like actually here and i think that's a shame because lightning is like again is a technology works today and you can use it yeah that's why i had some trolls in my mentions the other day like hopping in my ethereum thread from that

started in 2017 about them transitioning to proof of stake and not transitioning to proof of stake and they were like oh what about lightning i was like it works like i use it every day like what are you talking about it's here yeah um i i don't know what's gonna happen over the long term we'll see how technology emerges but i really i always like to say this is like i i have a lot of respect for the bitcoin developers in that 2015 2016 era of it was dark it was dark it was gloomy um i was in iowa and uh um the uh you know the developers really had a great view on how to scale the system and like what the fundamental principles of were of a blockchain were and like even you know i didn't understand that at the time and thought yeah let's just

do this like why not why are we causing a big hubbub about this and i think it's really paid off over the long term and you know i i'm very bullish in the direction bitcoin's heading specifically me as well and actually you're i think this mindset and uh more importantly the creativity of developers working on the protocol level level is rubbing off on people developing a lightning network too because i saw alex bosworth tweeting about where he wrote it in his newsletter uh about updating commitments once we get a snore signatures and a lot of people thought we were gonna have to uh channels were gonna have to shut down and you're gonna you're gonna have like a little bit of chaos on the latent network but it seems like at least he believes that

it may be possible to do that on the go yeah well i mean i think uh fundamentally like you know i don't know if you know much about this but yeah i haven't seen the tweet in question you can you can have the old old htlc scheme and the new like ptlc scheme running concurrently can't you uh yes and no i mean you can't route a ptlc through nodes that only know how to use htlcs and stuff like that so it's it's not simple but certainly it's doable to have a smooth transition i mean we've got version bytes everywhere just waiting to be updated like we thought ahead when we made this no one thought that this was going to be the final version of lightning so what do What do you mean by that, the version byte's in place?

Anywhere you look in the Lightning protocol, there's hardly a message to be seen anywhere that doesn't have a version byte involved with it. Is that similar to version bit at the protocol level? Yeah, version bit, version byte. Essentially just like a tag to say how you should interpret this that is updatable and where you know if it's something new that you don't know about rather than just being completely confused and there's also kind of this notion and the lightning spec that it's okay to be odd meaning if you receive an odd version bite or bit

that you don't um understand like if the number for that version is odd then you can safely ignore it and if it's even then you're supposed to like shut down like do not talk to that person and that's kind of like the to make us I I mean, this is a bad analogy, but like hard forks versus soft forks, like you can update to make things break by using even version bytes and odd version bytes it's okay to live with without understanding what they are. And yeah, just generally, I like to think that the Lightning spec has been built in such a way that it is changeable with some effort, but doable.

I like that analogy. It makes a lot of sense. So let's talk about the different Lightning implementations. do these buttheads a lot um are they going to live uh are they going to cohabit with each other well i think that's a that's an interesting question i think uh you know each of them have their kind of own vision of where they want lightning to go and like this is um you see like some features being incorporated in other nodes or in some implementations that aren't necessarily supporting other ones and you know each of these teams have a limited amount of engineering resources you kind of got to pick and choose um i am hopeful that we can keep this core protocol

together and keep the interoperable nature of lightning while maybe having features enabled with certain sections of the network um so like if uh say lnd has some new feature that they've come up with they can implement it using a bunch of odd version bytes where they are not working under the assumption that everyone implements this they only communicate with other nodes that do and you can signal for features that you support on the network in your gossip and so you know your L&D nodes can maybe at some small privacy loss at least you know just to test stuff out you can find other L&D nodes and test out your new features with and without kind of requiring that it become a part of like the bolts or something like that immediately it's fascinating

because that's like one like one of the big uh questions are like competing implementations can they live together and that's been a question in bitcoin since as old as bitcoin the nice thing about like lightning is it is just a fundamentally different kind of network whereas uh you know bitcoin we all need to come to consensus on who has what um whereas lightning is kind of like this routed network where me and Nadav can live in isolation and transact with each other without disturbing you ever. You don't need to make sure we're not inflating money or whatever. It's just on, like, say if Nadav was counterfeiting money and I didn't verify it, I'd be out. But the underlying blockchain itself, Bitcoin or you as another Lightning user would be fine with that.

So there is just less dependence that flows through the network that everything is like properly accounted for. I mean, obviously, if you're a direct counterparty to somebody, you want to make sure that they do have the funds that they claim to have. But you as a third party observer are not going to be harmed by that. Whereas in Bitcoin, you can print if there was an inflation bug about a year ago, that would have affected everybody because it was on the base blockchain level. Yeah, so going back to auditing your peer and the lightning network. How would you do that opening a channel? Let's see if I can remember so the bolts keep changing so this might be an out-of-date view of how this works, but um So there's some information that is known about you as a node Assuming your public node just from your kind of broadcast about yourself

There are these node announcements when a new node comes to the network and opens a channel that get gossiped around to everyone, and they, I believe, include some feature information. So that's one thing you can know then when you open a channel with someone, assuming it's a public channel, you also have a channel announcement that gets gossiped, which tells you about the version or the feature versioning information about that channel. Right now, say you want to open a channel with a direct counterparty, I believe you negotiate these features during the open channel messages, but someone should definitely double

check me on that. But by taking it a bit more abstract, essentially you via messages either from the counterparty or from gossip can gain information about which features they support and then furthermore I believe if it's like channel specific stuff that doesn't need to be gossiped when you reach out to them and you're like, I want to open a channel, then you specify like what features you want there. And if there are any even features they don't know,

then they like, I'm good. Cut you off. It makes sense. So like if you're going to open channels, like, Hey, if I'm an open channel with you,

I need to know this, this, this, and this. Yeah. So you can imagine in a future where we're using PTLCs, you know, Schnorr based,

uh, lightning channels, you could, well, it depends on how they're implemented but there's there is a world in which we transition via adding some some feature stuff to channels where some channels support htlc some channels support ptlcs and i guess i i just want to back it up a little bit here with like actually confirming that your user has the funds they claim to have because lightning had a big bug earlier

this year about this rusty called that out right uh yeah so the funny thing is everybody had implemented the spec correctly but the spec was wrong so well it left something out yeah i call that wrong when you don't validate the other person actually has the money they claim to have but like so that would have been an example of let's say again nadav had opened a channel with me i didn't go verify on the blockchain that nadav actually had the funds that he claimed to have and then he could start routing things through me uh and send i would be sent say he wanted to route something through me to pay you marty or tftc um i would you know how lightning works it works actually where i pay you and then nadav pays me however if nadav if i didn't actually validate it

that nadav has the money he claims to have i would just be paying you and nadav would be like see ya it's just like a it's just like a fuck you attack right yeah um so going to the point of it is very important to validate that people have what have what they claim to have on the blockchain because that is the collateral that backs this entire system and again lightning uh i i think rusty claimed responsibility for that although it was a bad enough bug that somebody should have oh No, I wasn't trying to blame Rusty. I was saying he made it aware on the mailing list. And all of the implementations had this.

It was just bad overall. That's a bad fuck up there. Yeah, that's a bad fuck. I think I remember tweeting that like, yeah, it's a bad look. But that's a good thing about the Lightning Network, right? Like you get to export this experimentation above the protocol level.

So mistakes like this are less, I don't want to say severe, but catastrophic to the long-term survivability of this system. Yeah, and again, it's just the different kind of setups and architectures of these cryptocurrency networks. I think maybe that's the generic term. Whereas, again, a blockchain, everybody needs to know about everything that's happening there.

Whereas Lightning, you can live in your own little universe without having to have everybody concerned about what's going on. And more and more so with the new proposals around trampoline routing and various other ways of kind of being a lighter node who only needs to know just about like their neighbors and some other information. And yeah, there's no, you know, dark looming threat of consensus problems lying overhead. Well, let's jump into that like routing. The routing is like huge, obviously. it's a bit of a problem not a problem but it's could be a problem to be solved a problem to be solved exactly so things like channel factories help with this correct um depends what you're

trying to do i guess uh are you talking about just like routing in general like liquidity management yeah just just making sure that when i go to pay an invoice it gets routed totally yeah so there's there's all sorts of considerations and tons of people working on this uh renee's he's getting his phd on this topic i think um renee picard yeah those that don't know go look at his demos on youtube totally um yeah but essentially you know there's the issue of managing your own liquidity which is kind of like there's uh this difference between inbound liquidity and outbound liquidity where some or all channels uh kind of have a fixed amount of money that can be in them, but it's directional money. So some money can be spent and some money

can be received from my point of view. And if I've got some channels where I only have spending money and some channels where I only have receiving money, it's usually going to be in my best interest to kind of try and move my money from where I can send it to where I can receive it so that it's kind of balanced. So I've sending and receiving money everywhere so that people can use me for routing um because if i only have receiving money somewhere then someone can't uh i can't route through that channel yeah uh but so there's proposals about doing that kind of generally via your like friend of a friend network like keep a small picture of people you're connected to and who they're connected to and then like maybe we all because everyone will

be doing this do like kind of free payments to ourselves or maybe we like pay some tiny fees to just pay to ourselves and then there's some proposals I think jits just in time routing is about kind of doing this rebalancing as the rap like as I'm actually so someone's trying to use me for routing and I'm not ready for it I can like rebalance my channels and then finish the route rather than what we would do traditionally which is just fail the payment and there's there's lots of other kind of considerations going on there but like loop in yeah so So, I think loop-in, loop-out stuff applies more to channel or liquidity management in the sense not of where my money is on the Lightning Network, but whether it's on the Lightning Network.

So, I can take money off the Lightning Network and bring it on-chain, or I can take money that's on-chain and bring it onto the Lightning Network without having to open a new channel. yeah so like uh you know going back to kind of like big economic entities like the concern there is you know i've got i started with a channel with somebody they had a thousand bitcoin on their side of the channel and then we've transacted a bunch and now i have a thousand bitcoin on my side of the channel like i don't want that on the like i want to take some of that money offline and that's uh where the loop product comes in um going and just talking about you you were hinting at this earlier um you know we've been writing a lot about this enterprise kind of grade lightning node stuff and uh part of there there's considerations in there with liquidity

management as well um you know so let's uh let's let's make an example out of this uh cash app great company cash app uh let's assume they were uh you know operating a very large lightning node and they have people constantly transacting with them, depositing money into Cash App, taking money out of Cash App. They, again, have different infrastructure requirements than smaller economic entities have when operating a Lightning Node.

So this blog post series that we've kind of written about this enterprise-grade architecture came out of conversations we had at Lightning Conference with some of the biggest exchanges in the space about like, hey, what are your just baseline requirements for operating this stuff besides security? And like the first thing that they said was being able to fail over our nodes.

And what that just means is if one node goes down, I need to be able to spin up another node within seconds and continue customer deposits and withdrawals. Preferably without a person involved. Preferably without a person involved. So I have like a kill switch already. Not a kill switch. a reboot switch more like it so like you know whatever happens you know stuff goes wrong in

software and computers all the time um you plan for lightning strikes that was a really bad one i love it talk about dad jokes yeah right jeez um uh so yeah uh you need to be able to reboot your your node quickly and continue operations and like this really got us thinking um again about what are the unique challenges that come with operating a lightning wallet uh compared to operating a normal on-chain wallet and uh you know we came out with a kind of a bunch of different answers um i'll talk to the liquidity management piece first because uh that's kind of what we were talking about before um if you have a lightning node it's well connected there's a bunch of liquidity coming in going out of it your cash app you know you're doing business

and that lightning node fails the naive thing to do is just spin up another lightning node instance right like you know you spin one up uh elsewhere on aws you ask people to connect to that one then and you've got to wait the 60 minutes or whatever it is for confirmation time. Then you have to force-close all the other channels. You have to force-close all the other channels. Move those funds into the new channels. You also have to have people just find the new node. It's a new node ID.

It's a new IP address, possibly. Someone's got to pay those fees. Someone's got to pay those fees. So, you know, we started looking at kind of generally how these nodes are structured And, like, how can we make it so that if node A crashes and burns, which is, say, cache app's main node, and we need to boot up node B, how do we make sure everything that was pointed at node A can be safely transferred over to node B as if nothing happened? And we figured out kind of the components of the lightning node architecture we need to tease out and pull out of that one machine that could possibly fail to be able to boot up this node B in a seamless way that allows people to continue operations in a matter of seconds rather than having this kind of purgatory where you've got all this liquidity going to a totally failed node and everybody needs to bootstrap liquidity around this new node. And to be clear, node A and node B are two users, the same node. They have the same pub keys.

They have the same node ID. They look the same. The fact that they're different nodes is something that should only be known by the people who have a node fail. And let me try to describe how you guys set this up. So node B is getting updated every 30 seconds, correct? And it's got like a pro, how do you say pro test? Prostagil? What's the database that you use in the back?

Oh, Postgres. Postgres. There we go. I told you I'm not a good developer. Yeah, so the... Postgres. What Marty's kind of pointing to here is like the key part to take out

of these current Lightning nodes, the way they're all set up right now is the database lives on the same machine that the rest of the Lightning application logic lives on as well. So if you make this database remote, that means you can now spin up another node in the cloud and then point that node

at this already existing database and safely transfer over all that information. There is a catch here, though, and this is the 30 seconds that you're hinting at. You need to be very careful to make sure both of these nodes cannot access the database at the same time, because if they do access the database at the same time, this can cause a weird corrupted state on your lightning node, which would mean that you possibly risk losing funds on the network because you are out of sync with your peer, more or less. So the 30 seconds is a lock timeout where node A has exclusive access on the database. If it doesn't update that lock, the lock expires and node B can obtain that lock and then continue as if nothing happened.

Just move from there. So if anything, there's maybe a 30 second delay in your node being operational. And I think 30 seconds is conservative personally. And also there's lots of optimizations right now. we're literally just doing like one lock for the entire database we're not caring about like all the channels are lumped into one group etc and so uh this will certainly be improved upon a lot in the future but yeah so right now the thing that we're kind of describing the thing we have working has a uh is it 30 seconds on the thing that's working yes yeah uh has a 30 second delay for

this for this failover to happen but that's just because we're being scared and i mean i think like our overarching goal here is to just make normal software people comfortable we're trying to reduce the problem of operating a lightning node down to common software problems that people face every day in the software engineering or devops industry we don't we want to reduce the number of problems that are specific to lightning to and uh so that people are just comfortable with this stuff so Yeah, so for example, the thing we've described essentially is to make lightning nodes stateless and move the state elsewhere And then we can kind of take these stateless things and if one goes down we can boot up another one without having state change

And this doesn't solve the problem because now we have the problem of like well How do you maintain the state and make sure that isn't a problem? But that is something that's already dealt with in industry all the time is just like how do you manage a database when it needs to be up all the time and it needs redundancy and all these other things and there are just solutions out there for them. Yeah, and it seems like the architecture

of this fallback system is simple enough where you can have even more redundancies than just the one fallback node. Exactly. And another problem that comes along with this, going back to if node A and node B aren't the same node, Lightning has a unique problem where invoices are signed by the node that serves them.

There's a digital signature on them. So that means node A and node B's invoices, if you aren't using the scheme we just talked about, are fundamentally incompatible with each other. That means you cannot pay an invoice that node A gave you. You cannot pay that to node B. Whereas Bitcoin addresses, it doesn't matter what wallet it's served from, right?

Like you can get a Bitcoin address from anybody's wallet. You can always pay to it. um you can imagine with large bitcoin exchanges like they have customer support ticket issues already where if anything is different or weird or comfort you know things aren't confirming on the network they get a bunch of support tickets that's going to be something that ends up being a problem in like these failover schemes uh as well so that's another thing that we uh think is like cleanly solved by this kind of um architecture that we're talking about yeah out so i mean it seems like a no-brainer like a necessary uh product if we want to take it to the

enterprise level right yeah yeah though it is probably worth mentioning that this isn't done without trade-offs and so the the reason that you know you might not want this done to like your mobile wallet or at least not like your personal like if you've got like a cosmonaut at home or whatever the issue is that and this is kind of an issue more generally true for lightning channel backups which is essentially what we're doing by taking all of the state externally and making sure it's redundant and so on and so forth as we get like backups for free so we're doing backups and also a bunch of other stuff so we've got these kind of enterprise standard backups and the the

well-known cost on Lightning right now to doing backups is that you have to backup and write state externally to like a different machine in this case maybe in a different state maybe in a different country every time you update anything on any of your channels meaning if you're routing meaning if you're paying meaning if you're receiving and so if like every node on the network adopted these backups, suddenly routing would take forever. Because it would just fuck with latency. Yeah, because essentially, say you have some crazy 10-hop route.

Now every single node along the path, you're adding network latency of not just communicating between peers, but also each peer or each node or each hop on this route also has to go talk to a database in some other place. so it's analogous to full nodes uh gossiping new blocks to each other uh is that correct so the the difference here is that what we're adding is not more latency between peers but rather we're adding like a bunch of external network latency okay which is much slower and this may be something again like uh we are taking for granted because we went through like the steps

for this but um there is a lot of messages that need to be sent back and forth between lightning nodes to actually complete a payment i think it's five it depends on when you start start and stop counting okay so i mean you can update a bunch of things at once and there's all sorts of other stuff going on and what nadav is talking about here is he's saying so there's let's just say five messages that need to be sent to complete a payment that means for every one of those five messages being sent you go to the database you send the message you go to the database you send the message you go to the database you send the message like so like that and that's just to do one payment so that kind of like adds up takes time and again as nadav was kind of hinting at

if you have this 10 route uh or 10 hops on the routes that means everybody's doing that so it's like you kind of have this 50 database rights yeah so um you know i don't know how many how much people this is i think an ongoing question with lightning and i'd like to hear your opinion on this but um this is i i don't know if i see a lot of concern about latency on the lightning network and do you like i don't know do you think that's a concern or not a concern or where's where's marty at on this or have you thought much about it and that's okay if you haven't i get pretty pissed off after five seconds yeah like was that like i use zap uh it's my go-to lightning wallet and once the uh once the circle goes around the lightning bolt like yeah six to ten times i'm like

What the hell is going on here? And then I start worrying and I go back to switch to my invoice. See if that got paid. See if that was completed and back to that. That almost causes me more anxiety than like doing an on chain transaction in that sense. So like, I mean, this is something I want to make sure we as a network aren't totally forgetting about is like, you know, if we want this nice payment UX, we need to make sure that the things that we know we're building in, like don't incur like a ton of latency overhead to, or at least we have systems. the network is somewhat designed around that stuff or at least you know put it in as a consideration so and i think part of the issue is right now uh lightning isn't necessarily or

most of lightning use isn't necessarily a bunch of like really latency sensitive activity it's like i'm gonna send you a little bit like just a little bit or uh yeah things like that you know y'all's things like this i mean it's not that these things aren't you know as you mentioned like if it's going longer than five seconds like that's too long but as opposed to like if currently all lightning was being used for was high frequency trading like we would be having a very different kind of tone around the discussion of like our backups okay yeah yeah no totally and it comes down to like who you have channel or channels open with right like i there was a new service new lightning service that spun up and i paid an invoice uh to that it just became like

it becomes if you've used lightning long enough just became obvious that uh the channels i had opened were not connected to this node obviously i didn't have a direct channel open with this node and maybe it wasn't connected to the peers that i was um but i might be like a a more technical user than uh our target end user at the end of the day so i don't know if uh other people would recognize that and be like oh this is what's going on yeah i should open channel um i i agree with that um yeah the routing prop like i don't know there's also a security story on who you're opening channels with too like you have you probably should open channels with people you know especially you have a lot of money on lightning because the security model is slightly

better going back to the private key stuff we were talking about earlier um they can steal less money from you if it's somebody you have some trust in yeah and so essentially i think what what you're referring to is that um if you're you know you're looking at all the different keys some like if you lose your funding private key like too bad uh or no actually here this is a great example if you lose your funding private key um and you lost it to your counterparty then too bad they can just literally spend the two of two multi-sig on chain now if you lose your funding private key not to your counterparty or your counterparty is friendly and it's someone you know and someone you trust then you are not at risk of losing those funds and you can just

force close the channel or they can force close the channel um without really any any risk assuming that they are friendly to you so the the security story for whether or not your counterparty is someone who you trust uh really changes the game and uh that might mean that like in the future you have your larger channels with people you know and a bunch of small channels with people you don't so you could still have access to those funds but without really exposing yourself as much to having those hotkeys be stolen

because many of these hotkeys if you trust your counterparty they kind of act as like you're on a two-for-two multisig with them and if you lose your keys depending on which keys they are then they can actually protect you from losing funds. No,

this just seems naturally how, how I created my channels and fatter channels with people that I know. It was meant to be. Which is, I guess like how you'd expect things to work out. I think if lightning does evolve as like a, say retail payments network is like you probably connected people, you know,

or connect to, you know, retailers that you do a lot of business with, or maybe liquidity providers along the way. um i don't believe in the model of just like closing my eyes and like pointing into the network and just randomly connecting that's why i never liked autopilot yeah i think that's probably a little misguided i don't i think that is autopilot kind of going away or is it unpopular um it was very unpopular like i i shut it down as soon as i yeah i'm sure it'll get better

eventually it's it's uh from what i've heard of of people who have used it and not liked it it uh it's not not ready for for prime time yet but uh i i i don't know i i can't imagine that like 20 years from now we don't have like an autopilot running our liquidity like there's no way that we're going to be managing all of our own liquidity as just normal users of the lightning network yeah but it's it's certainly a really hard problem no definitely but i think a lot of people who are like oh this needs to be perfect out of the box number one are impatient and number two well they're using lightning so it might make sense yeah but but again like this is lightning you still are your own bank at the end of the day like i'm a

company like when i was creating uh opening my channels when we first spun up our node like i treated it like i was opening like a company bank account opening the company bank account took me days where the checking account yeah exactly and uh opening the lightning channels only took me less than a day a few hours of just dming people being like hey i'm gonna open the channel with you would you please open back buying some liquidity on uh lightning power users buying some liquidity on bit refill um via thor um and like a lot of people like want this to be perfect out of the box but again if we are really taking this stuff into our own hands there is going to be some some work by the end user that needs to be done because the benefits of the network are

such that it's worth it i think yeah and especially at this phase where like i i would be surprised if very much of like i i think i think a vast majority of the words in the bolts will be changed over the next couple years uh you know we were well once we get taproot we'll we'll have schnor and we'll be able to have PTLCs instead of HTLCs, we'll... What's the difference between them? Yes, so... We've been... Sorry, my bad.

No, that's not your bad. Yeah, HTLCs stand for hash time lock contracts, so that's essentially just a contract where you... So the hash lock is you can have this money if you reveal the pre-image to a specified hash, and then it's also time locked, meaning the other party can claw back the funds if you don't claim these funds with the pre-image to the hash after some time lock. So that's an HTLC a PTLC is very similar It's a point time lock contract where instead of a hash lock which says you can claim these funds if you have the pre-image to

this hash It's a point lock meaning you can claim these funds if you have the pre-image to this point where by pre-image I mean scalar and by scalar and point you want to think private key and public key So I think math speaking, you know, you've got points on an elliptic curve We have our numbers which are private keys You can turn any number into its corresponding public key, which is a one-way function, or so we claim here in Bitcoin land. And hashes are also one-way functions, but they're quite destructive in that, like, you don't get any nice properties between your preimage and after the function. Whereas when it comes to private keys and public keys, they actually do have some nice properties.

Like I can add two private keys together and then if I took the public key I'd get the same point as if I added the two public keys for those private keys together So you kind of when you're hashing you're destroying useful non-sensitive information and So by using points instead of hashes we still keep things one way like you can't compute the private key from a public key We've got much bigger problems than like how's lightning gonna do if you could do this like that would just kill the base layer um but so you still have that one-way property uh where revealing the public key tells you nothing about the private key but it still gives you these nice properties where you can do a bunch of stuff

and so ptlcs are better in every way than htlcs uh for lots of reasons they actually seem easier to explain just point at a point on the curve yeah only totally so instead of using hashes as our kind of irreversible reveal the pre-image to this wonky one-way function rather than using hashes just use points or using public keys like reveal the private key to this public key to claim these funds and would a point be like a uh think like a public key yeah but i'm thinking like a bad analogy okay like uh you an analogy man too because i am um no i'm terrible at analogies but like a GPS coordinate, like on the hash curve. A GPS coordinate on what, sorry?

On the curve. Yeah, I mean, it's coordinates. Yeah, coordinates, there we go. A pub key, despite being like 33 bytes of hex, so like 66 characters of hex, that's actually just like an X coordinate and one hint that is all you need to compute the y-coordinate. Yeah, why even bring GPS into this with an x-y-coordinate?

Yeah, I'm sorry. That's okay. I liked where you were trying to go with it. I was like, God, that's a good idea. We need to figure out a good analogy. Yeah. I think just using the x and y-axis is allowed. Yeah, it's all right.

But yeah, essentially, right, point being, lightning is going to change. And not only is big structural stuff like that going to change, but we get changes in all the time like I know this isn't recent anymore but like TLV's got added now you can customize what's inside of your onion we're adding new features all the time

I think some implementations have actually added support for these kinds of things I know L&D has and yeah just generally I mean we might be getting L2 someday if we ever get sig hash no input on chain. That's E-L-T-O-O

for the freaks out there. Yes L2 I mean, I think, so have you heard of PTLCs or this idea of using points rather than like hashes? You guys are like somebody who prides myself as trying to stay up to date on this stuff. This is like a very interesting thing because I think this is like, I think this is maybe the most significant thing that we can do on Lightning to like improve just a bunch of stuff. And maybe the reason it doesn't get talked about more is because it requires a base layer change, right? Yes and no to almost everything you said. so let me get into it um so uh it's it's criminally under promoted i feel like these ptlcs because like are you saying i'm doing a bad job chris well i mean like i feel like i'm it's probably

my responsibility but like this is something i you know i hear that's kind of like rumblings in the technical community that is not necessary for some reason is not making it to the forefront i don't know if it's just because we've been like uh like we need to change the base layer and we don't want to talk about things that like that require a base layer change or yeah so there are a couple reasons um one is as you kind of mentioned it's not something we can do today uh as is so it's not something we necessarily require snore for there are other ways of achieving this but none of those are implemented either so seeing as snore does achieve this and it achieves it better than any of the alternatives no one's working on anything that could work today

Might as well wait. It seems like Schnorr has a good chance of getting in. Yeah. Come on, Chris. Stop it with that. Okay. No. All right.

Quickly, why not? Well, I mean, we're still changing the Schnorr BIP. Not in any serious way. It got modified this week. It was a tiny little tweak. It'll happen. It's fine. Okay.

I am proposing a prop bet for everyone out there that's listening, all your freaks. We're going to make a DLC for this, I think. Don't spam my Twitter, but spam Marty's Twitter and maybe Nadav's about January 1st, 2020. Have we deployed that one? I'll take you on the first one. Have we deployed the code to activate Schnorr or not on the Bitcoin network?

Like our nodes. Not having an act. Yeah, exactly. Is there a release of Bitcoin Core that contains the code to have it activated? I'm going to let people smarter than me debate about that. that that's i've been i've actually moved the goalposts i've been asking people that question since october the clear over i used to say is it activated by january 1st 2021 almost everybody

said after that and now i'm saying is it deployed by january like as in again a bitcoin core release that contains this stuff is it deployed by january 1st 2021 so i want to hear people's opinions segway took a lot longer than people thought it would yeah guys let's not jinx it too much sorry for interrupting yes and no to all my questions yeah okay ptlc's um yeah so so the first thing is uh you you need uh to be able to implement point locks on bitcoin this most likely comes in the form of what are called adapter signatures schnor gives you adapter signatures for free we could uh add some like zero knowledge some since relatively so it's all relative relatively light zero-knowledge proofs to libsec pzkp and implement these things without Schnorr,

but no one's going to actually work on that because we're working on Schnorr. Once we have adapter signatures, then we can now do a bunch of other stuff, but basically it's like once we have Schnorr, then we can do a bunch of work, and then after that we can get all of the fruits of our labor so um kind of some things do come for free though so you get uh the moment we have a snore uh payment decorrelation i feel like is is pretty well known and i'll explain what it is um amongst developers so right now the uh have you heard of payment decorrelation before marty i have not okay so payment correlation so you'll know what it is though it's um if you are paying someone on the lightning network it's going through a route you're using a hash to synchronize

all of these payments, everyone's using an HTLC with the same hash, so that once the person getting paid reveals the preimage, which is how they claim funds, in order to claim those funds, they must have revealed the preimage, which means the next person can claim their funds, and it goes on and on and on. So the problem with this is that every single routed payment on the Lightning network links every single hop. if the hops along a route are communicating with each other, say you have like two nodes and they're friends

and they're like gossiping to each other. Just real quick, it's the same pre-image that's revealed through every. Along the way. Yeah, exactly. So you can only move it to the next stop if you reveal it. Yes. Or you can only claim your funds

if you reveal the pre-image to the hash. But if someone claims their funds from you, that means you must have learned the pre-image and you can go claim your funds. So you're never at risk as a router because you have the same hash set up on the person who you're receiving from and the person who you're sending to.

And so that's what makes it atomic is it's made atomic using this hash that's all the same. The problem is if the hash is the same everywhere, say you have like, or someone's paying through the three of us and me and Marty are sitting on the ends, by the way, and me and Marty are just chatting with each other

about all the things that we see and we both notice that we both added an HTLC that has the same hash on it and chris is an innocent bystander in the middle just trying to make an honest day's fee work and um so what happens here is i set up an htlc to chris chris sets up an htlc to marty marty sets one up elsewhere and someone has one set up to me before all of this and they all have the same hash so we can immediately tell that we're on the same route and now when the claiming happens marty's the first person who learns the pre-image because the person who got paid claimed their funds claim claim claim now you've claimed your

or now you are ready to claim your funds um but what we can do if we cooperate is you can tell me what the pre-image is skipping over chris cut chris out so i'm supposed to go to chris but i can just hey you could just talk to me and give me i know that you know that i know and then i'll go claim my funds and like right we're we're cooperating we trust each other i'll send you the funds i would have had to send chris otherwise um and so on and so forth so what we've done here is a we've stolen all of the fees chris would have gotten and it chris could be like a bunch of nodes in the middle right we're just like two nodes we don't even know how far apart we are on this route but we know we can steal the fees of everyone in between us and not only can we steal

their fees but say marty's you know had a bad day feeling malicious he can like not fail malicious malicious marty malicious marty that's a good uh yeah that's a good acronym right there um so he can decide not to fail his payment to chris and just like keep chris's funds locked up in their htlcs until the timeout of that payment which can be quite a while so it's a free attack it's a grieving attack as well as a fee stealing attack it's also a huge privacy problem because you can set up a bunch of nodes around the network to like and you're economically incentivized to do so because like you can make money by doing this by stealing fees um and you can just set up a bunch of nodes on the network listen around try and get on the same routes and also try and build

a network of who's paying or a picture of who's paying who so this isn't hash world now if we move over to ptlc's like i mentioned points have this property where if i add them together the pre-image to my new addition point is actually just the sum, the addition of the two pre-images. So what this lets me do is, me as the person setting up the payment to some other person on the network, I can add a random nonce to every single hop so that they all look completely different, like I've added a random number at each step. And so no two people on the same route have recognizable linkage between one another, and more so they can't do this bypassing of the people in in the middle because they literally have different pre-images the math would be wrong

exactly and so the protocol works out so that every single hop when you're routing tweaks by their tweak um and you tell each hop what their one tweak is uh the pre-image to their tweak only um and then the person who you're paying you tell them the sum of all the tweaks so now they just have to reveal the one thing they know their pre-image plus the sum of all the tweaks to the person before them and then kind of the tweaks unfold on the way back so we've added numbers on the way up and then the numbers get subtracted on the way back to where i'm the only person who learns the pre-image to the thing that was in the invoice so the uh the tweaks the nonce tweaks along the way you may not necessarily know every node along the way but you can say hey

uh node one gets this tweak node two gets this tweak you don't necessarily know the specific nodes uh is that correct in in the lightning network when you are setting up a payment and you are the person paying like the originator of the onion you set up the entire onion you choose your route and you know every single node along along the okay so that happens okay that happens upon initiation of the invoice yeah so so the person who sets up the payment is uh also the person who generates a bunch of random numbers and uses them to tweak everything along the route um and so that's that's kind of like the uh probably main motivation that uh is behind ptlcs like there's a pain or a paper called uh atomic multi-hop locks is i think where a lot of this

sanchez or pedro i don't remember i'm sorry thanks though um but yeah great work a lot of this stuff got formalized there and with some like security proofs and such and they also did a lot of work on kind of formalizing what a wormhole attack is and why it'll always happen in payment channel networks like the one we're in right now. So now that this is out there, it's been a while, and we've come up with a bunch of other new things that you can do with payment points.

Segway. Segway. Segway. Segway. We love Segway. Segway to DLCs. Oh, okay. Yeah, we can get there.

Okay. Okay. Well, that's what I was going to say. We've been getting very much into the nitty-gritty of the technical details, but I'm happy. I love getting into the technical details. Sorry about that. That's my natural state.

But yeah, let's... What are we going to be able to do with this shit? Like, what are the use cases? Totally. So with this nice additive property, you can do a ton of stuff. And I've written many blog posts, and I'm in the process of finally getting around

to the new series of Payment Point blog posts coming to you soon at sherdberts.com slash blog. But... Good show. Plug. But yeah, anyway. Um, uh, so you can, uh, essentially there are a lot of proposals out there right now where you sacrifice, uh, proof of payment, uh, in order to do something cool.

So for example, atomic multi-path payments as they are implemented, uh, today, actually as they're not implemented today. So that's multi-path payments, AMP, the other proposal for how to do this stuff, uh, and many proposals out there have this problem where since the person who's setting up the payment has to do a bunch of stuff they actually end up having to know the pre-image to the hash in order to construct any of this now that's not a problem if the sender knows it it's only a problem if people along the route know it but it is a problem because they can't actually learn anything atomic with payment completion you don't get a receipt for your payment if you're doing an atomic multi-path

payment uh it's called the proposals like og amp they're like multiple amp proposals but um so you just know that it was paid yeah and there are a lot of things like this so a spontaneous payment is the simplest one just real quick because you skipped over this really quickly is a proof of payment in like it is just this hat pre-image that we've been talking about being revealed or one of these uh private keys that essentially being revealed around along the route yeah so uh But today in the Lightning Network, you can use this hash preimage from the HTLC as a receipt of payment. Because you get it if and only if the payment completed, because someone must have claimed their funds from you in order for you to receive this preimage.

So it can be used as a receipt on the application layer and your accounting stuff. It can also be used to make things atomic with Lightning payments. So say, like, I send you a bunch of data encrypted with the hash preimage. and now only if you pay me can you get the key to decrypt this data and you can do a bunch of stuff like that but if you want to do say spontaneous payments or invoiceless payments where i just pay you without you having to invoice me i had to generate the hash and so i don't actually get a receipt for my payment okay so this is the easiest problem solved with ptlcs all we do is you add a point to it and then there's the thing i knew that i had to construct to make this proposal work but

then you can always add something you know and I can use that as my proof of payment because I know the rest so I'll just subtract it away once I have the pre-image and you just send that along with the payment or you have or yeah it depends on the proposal for for exactly how like my stuff gets set up but say like you're doing an amp I set up a bunch of you know different sub payments and then I send you something and then only once you get all of those things do you learn what my secret is and beforehand I knew your secret and if you add those two things together now you can claim it and then i learned that some and i can just

subtract my piece away get a proof of payment or a receipt for my payment so that's the first thing which leads us into the next thing you can do adding points to stuff and that is say you have an oracle someplace that is just broadcasting schnorr signatures of whatever say like is the bitcoin price going over 10k this weekend this is the hodl not index so will it ever go up yeah you've got to put a time lot time uh out on that for this to work but anyway um so say you have an oracle of something and you want or a better way of putting it you just want a payment to be contingent on a signature it can be from a person it can be from an oracle it can be from whatever so let's be specific with this ten thousand dollar example it could be something

like Crankin or Cash App is using an Oracle service, like, hey, we're going to give you our price feed, you can pay for that. Totally. Is that a good example? Yeah. So they would have to do something specific where they are broadcasting Schnoor signatures of things in nice formats. But so long as they are following a spec that we're working on, that should be fine.

Any person who has data can just sign that data, and then those signatures can be used to make contingent payments. So essentially, what I can do is I, Schnoor signatures have this nice property where a Schnoor signature is just a number. And every number has a point on an elliptic curve. If I treat it like a private key, I can compute its public key. And it turns out that the point associated with a Schnoor signature, you can get from just the person who's signing their public keys. I can use your public keys and the message that you might sign to compute this point whose pre-image is your signature. Let's be specific here.

What's the message in our example? Yeah, so in this case, the message would be like, over 10K, three exclamation points. They're either going to sign that or they're going to sign sad. So those are the two options that they've said in their API docs or wherever else that are publicly known. They're going to sign one of these two messages. And probably if they're responsible,

they should also serialize those messages into like hex or something so that people don't mess up when they're doing that. but anyway so we've got these messages that they are going to sign and they're going to sign one or the other and i want to make a payment contingent on the it's over 10k uh is that shoot was that what the message was triple explanation let's make sure we bound the time interval too totally yeah so it's it's uh by the end of this weekend specifically by block x right yeah by uh you could do a time stamp or whatever you want it's just an oracle they're just broadcasting a signature um so you can you can do your time out however you want but you should

make your event specific to like some time period or some interval that's where i fucked up in my explanation i think i thought it needed to be a block time got block height versus that there are block things and definitely could be and it could be a block time but uh the actual oracle who is specifying an event and assigning something for the event they can do whatever they want and like The key thing here is it just boils down to a digital signature is what the Oracle is serving. There is no actual knowledge of the Bitcoin network going on here. There is literally no knowledge of the Bitcoin network.

They don't even know that you're interacting with each other. They don't know about us. They're just going to post a signature up on the internet. Obviously, since I care about my privacy, I'm going to use Tor to go to that website so they don't even know that it's me. If I want, you don't have to, but you can. So yeah, the Oracle doesn't need to know about us. They don't need to know that we're using them

They don't need to know how we're using them. They don't need to know anything all they're doing is they are putting up a Schnorr digital signature of is it over 10k by the end of this weekend and They're going to put it up at the end of this weekend And so I make a payment on the Lightning Network in this PTLC world to Chris that has That signatures point as the pre-image meaning he can only claim this money if he learns the pre-image to this point which where the pre-image can we can verify this is like not trusting the oracle this isn't trusting each other we can verify that this payment will

only be claimed if he learns and reveals to me the signature where the signature would be kind of the proof and if we wanted to add another receipt from chris we could say like a point chris knows plus the signature's point and just like i mentioned and just uh like backing up and adding a little bit more commentary is you know we always need to design these protocols okay backing up even more um we are we are working on a dlc specification kind of in the same vein as the bolt specification with the lightning network we would like these to be interoperable with you know everybody in the community we have great partners with crypto garage actually so let's let's take an even further step back yeah discrete log contracts all right yes proposed by

at taj draja yep and at mit at mit in 2017 correct yeah that's a few years ago so this is this is um this is something i want to like i like to think i'm like up with the tech and uh don't like to write about things uh unless they materialize like there's a lot of stuff that hasn't materialized and dlc is something that's discrete log contracts again we're using an abbreviation here um has been thrown around a lot but i was like yeah is that is that real And then until last week, until you posted that demo, I was like, oh, shit, this stuff looks real. So discrete log contracts, the way I described it in the newsletter, you guys can follow up and let me know if I'm wrong. They basically allow blockchain agnostic, number one, and layer agnostic, it seems.

Totally. They allow you to create more private scalable smart contracts on these systems. Yeah, and specifically oracles. So, essentially, if you read the DLC white paper by Taj, it's, I think, five pages. It's not very long. And most of it is just describing what Schnoor signatures are. Like, I only realized halfway through it, I'm like, oh, wait, this is what all this Schnoor stuff people are talking.

Like, that's just this? Okay, that's not bad. But yeah, so most of it is just a description of Schnoor signatures and a comment on how you can compute the public key for a Schnoor signature without knowing the Schnoor signature. you just need the point on the curve right yeah so you can you can you can compute the point on the curve that corresponds that whose pre-image is the signature just from the signer's public keys is is the nice property that short signatures have and then simply like the next step that this paper takes is and this is has nothing to do with lightning this is entirely on chain

workable today we've done it today um is you can create uh i'll simplify a little bit and then i can tell you where i lied but you can create say like a two of two multi-sig where one of the keys is mine and one of the keys is just the point associated with a specific signature that the oracle could put out um and then i could throw that on like an output uh that say we're like speculating on something that the oracle might put out whether it's above or under 10k by the end of this weekend for example um and uh we could both like put money down into a two-for-two multi-sig between us and before we like sign any of that we create all these different things spending it whose outputs use these various possible signature points um one per event

that we care about think of it kind of like a lightning setup yeah so in your demo you set up It's kind of off-chain. Alice sets up three transactions, right? Yeah, and so we sign all of these off-chain transactions that spend our funding. And then we sign our funding once we're all good, publish the funding, and then we wait. And now if anybody broadcasts one of...

Or actually, they're time-locked, so you can't even do that because we changed the spec, so it's good now. Never mind. So now we wait, and then the Oracle, at the end of this weekend, broadcasts a signature. Shout-out Cash App. Yeah, shout-out Cash.

um pull that mic like right in front of your face shout out cash out no no not for that particularly not for that oh just in general just in general okay sorry you don't have to talk into it like this i'm saying uh oh make sure you're yeah yeah yeah i've i've been i'm gonna keep talking okay is this good now okay awesome my bad no no you're you've been coming out loud and clear cool so um yeah so essentially once the oracle has broadcasted one of these signatures before they did this first of all if any of these ended up on chain we wouldn't be able to

spend them because it requires this key for this 2 of 2 multisig but once they broadcast their signature that signature is like a private key in this scheme and I can use that weirdly I use that signature to create another signature of the transaction

and now I can spend that 2 of 2 multisig now the problem with doing I'll just tell you where I lied the problem with doing a two of two multi-sig is that you literally put the oracle's signature points on the blockchain and tell everyone that you are using the oracle and this is a key thing I think to highlight here is the private nature of this uh scheme goals yeah yeah and like how it's maybe different than other oracle schemes is like how Nadav is about to say how the oracle does not know that you're using them and how important this is at the blockchain

level so that the oracle can't play games being like oh i see that nadav is speculating on this 10k bitcoin price and maybe i want to say something different now that i see nadav is like got this big old contract out there better it could be like somebody outside the oracle knowing that they should attack the oracle totally and so there's bribery there's bug bound or not bug bounties but just bounties uh there's all sorts of these kinds of considerations so the goal is the oracle never learns who's using them the oracle never learns how it's being used and the oracle can't even see if there's like non-cooperation and you publish everything to the blockchain they cannot see that they've been used um so it's fair to say in short no blockchain tanked right no no footprint no

footprint yes uh of any kind and so how we do this is we rather than just using like a two of two multi-sig on-chain. We add my key to that point with some other stuff. Essentially, we just hide it with some random stuff in such a way that only I can spend it. So it has to include a public key from me in this composition that's going to happen off-chain in a standard way. It has to include the oracle's point so that the signature is required. And then it has to be untraceable. It has to look random it has to look like a normal public key on chain so on chain it looks like a single key spent but it turns out that that public key is not actually mine it's only something for whose keys i can compute if i get a signature from the oracle and it's untraceable otherwise it looks

completely random uh and so all a dlc is is it's uh you have you've got like a funding transaction on-chain and then the oracle broadcasts a signature on whatever you've been speculating on and then normally two parties should cooperate just like in lightning we just like spend the two of two multi-sig as it should be but if there's non-cooperation or someone disappears then you don't need the other party this can be executed unilaterally by just publishing one of these off-chain transactions that we signed early on and that requires the use of the signature is how we actually enforce this signature the signature from the Oracle with the data yeah um yeah and that's that's what a discrete log contractor DLC is um it's it's essentially

a comment on how you can use Schnorr signatures uh to do stuff with like points it kind of you can see how this relates to my work on the lightning network with PTLCs um but it also is just a comment on how if we had a bunch of standard oracles, this is all just Schnorr signature stuff, like public key, elliptic curve math. So this is

not blockchain specific, it's not layer specific, you can use it anywhere. One discrete log contract oracle can be broadcasting signatures for an unbounded number of use cases. But guys, the oracle needs to be decentralized. Well, I mean,

the interesting thing about this is like you can actually you can aggregate oracles too it seems like you solve this problem though like yeah so so there's there's a some people may say the oracle should be decentralized and what they're saying is that even possible uh yes and no which is my favorite answer to any question this is our slack nadav yes and no no my my girlfriend's parents they they say i say it depends like it's a joke that i say it depends to everything um they think i'm too political but Oh, well, political's not the right word. You're too...

Too good at maneuvering conversations. Yeah, anyway, smooth. Smooth, smooth operator. That's what you like to think. That's not what they say. Anyway, what was I saying? Oh, yeah, yes or no to, should it be decentralized? So there are all sorts of...

Can it be decentralized? Can it be, yeah. So there's all sorts of... At a high, like, abstract level, the question is, my application requires trust, right? There's no way to do this on any blockchain, like a derivative or whatever, without having a source of truth for what the price was at the time that the contract matured, or whatever my application might be.

It requires a source of truth, and since it's not something about the blockchain, it needs to come from elsewhere. And it needs to come in the form of a digital signature almost always. So the problem is, where do I put that trust, and how do I mitigate that trust, are kind of the two questions. So mitigating the trust is one thing, but where should I put that trust? So some might say, decentralize your oracle,

which means take a bunch of untrustworthy sources and just spread your trust thin among all of those. Reasoning about security for these things, these decentralized things, is a mess. Usually rich people can just decide what the truth is in most of these schemes. It's a giant mess. Yeah, that never really made sense to me.

Yeah, and I think the reason that is is because we live in a world where there is trust. Like, we like to talk about, you know, trustless stuff all the time, but if you look at businesses today, like, A, they have recourse, and B, like, even in interpersonal relationships where, you know, I might not sue you

if you cheat me out of something, but, like, it does have consequences, and just we have a trusting relationship, right? there's there's trust to be had in the world and i advocate for rather than spreading your trust thin across random untrustworthy sources who could you know in in these contexts always be just one very rich untrustworthy source um instead uh you should spread it not too thin but spread it amongst multiple trustworthy sources and more importantly multiple trustworthy sources who were incentivized to give you good data and that's what I think totally your

solution yeah really solves with the ability to blind tip these Oracle yeah and and that gets into kind of mitigating the trust so the first part is like how should you trust and in my opinion it shouldn't be randomly but not much it should be like a little bit more but spread out amongst trustworthy sources for which there will be some kind of recourse is kind of the first mitigation. But then you get into some more interesting mitigation. So like you kind of mentioned, using the Lightning Network, and I don't know of any other way of doing this other than using the Lightning Network. The Lightning Network has a property where if I pay someone on

the Lightning Network, they don't know that it was me who paid them. Like the payee never learns the identity of the payer. There are caveats about information leakage all over the place, especially in htlc land but um generally speaking we have you know someday we'll have that property i'll put it that way um and we're definitely near that property than anything i know of right now um so we have this property where i can pay somebody uh and they can know that they've been paid for a specific invoice that they put out there um and they don't even need to learn anything about me other than that I'm like within a radius of 20 hops on the network which is probably like the whole network right now um it's probably more than the whole network right now uh

yeah it probably narrows it down to like not those three nodes but anyone else um anyway so you can do this thing where uh rather than just broadcasting uh the data you go to the Oracle via Tor or some other onion-routed thing that also protects your identity, or maybe on the Lightning Network once we have better messaging over the Lightning Network, and you, via them not learning who you are, ask them for an invoice for this data, and then atomically, like we mentioned, using pre-images, you can pay them where they get paid a small amount, and I get a signature in a trustless, atomic way, and it's essentially the same thing as I described earlier with Chris.

I make a contingent payment on them giving me that signature, is all it is. And then once I have that signature, I can use it in DLC schemes. So that's one thing, is we can incentivize them by making it a profitable business, where A, their reputation matters, because they've got some stake, they'll lose business. And B, like, here's some money, give me a valid signature, please. Just makes a lot of sense. mitigation is I can use multiple oracles um so there there are lots of ways this the easiest way is to just add them together make it like an n of n 2 of 2

within a certain variance or something like that to see in like the the data being within a certain variance totally yeah so you can you can do ranges I do you have any sponsors besides cash yeah I'm Shane capital within on sure sure both have oracles for whether or not the price of bitcoin will be over 10k at the end of this weekend and you can set up your contract using both of those oracles where they both must sign the same message in order for this to work and like some refund or whatever you want to happen happens uh if they disagree or whatever you can default to one of them you can choose to just refund both parties not execute the contract you can do whatever you want but the point here is

that the oracles don't need to know that they were both used the user doesn't need to tell anything to either of the oracles the oracles can get paid if they set up this scheme using lightning and they don't learn that they've been used even in the case where people aren't cooperating and everything ends up on chain for everyone to see um so there's that as well so another way of mitigating trust is use multiple things rather than just one and this is what you should always do you can even use thresholds so say like three of five four or five this gets much more complicated I won't explain how it works I'm not a hundred percent certain in any of the possibilities but I'm sure one of them

must work and yeah so there's that the the really cool one that is kind of just for free because these are digital signatures is digital signatures while any good digital not any good I shouldn't say that but Schnoor digital signatures ecdsa the signatures we use in bitcoin have the property that if you sign two different messages using the same keys then you leak your private keys so if you know i have my public key that's out there and people are expecting a signature with that key and if i using the same let's set this up with a concrete example yeah so say like we can't use cash app for this though because this is like bad acting sure bits no no we're not bad actors either uh uh mount gox mount

Mt. Gox, okay, sure. Mt. Gox, there we go. That's a good one. Yeah, Mt. Gox is in Oracle now, and they are here to make money, and they are going to tell you one thing, and they're going to tell your counterparty something else. Maybe they're not even here to...

Not even necessarily your counterparty. What it would be like maybe... Oh, yeah, you're right. Let's say me and Nadav have a bet on Bitcoin price being over 10K, and then nadav and marty have a bet of bitcoin price being over under 10k yeah um nadav is on both sides of the trade so with marty he thinks the price is going to be under 10k and then with me he thinks the price is going to be over 10k so i'm already being foolish you could grease

you could try to grease the oracle is that what we're saying uh or so here's here's uh But so what we're actually saying is say that the Oracle is being malicious in some other place and say they tell you it was over 10K, Marty, and they tell Chris it was under 10K. I'm going to lose all my money. This isn't good for me. So but I get a free mitigation against this. This is called equivocation. They're saying two different things happened.

If I ever see two digital signatures of meaning the same keys, different events, different messages um if i ever see those two things it's like pretty simple math you just like subtract them do a quick and whatever you you plug it into lipsec p whatever um and it pops out the oracle's private keys if you see two signatures you get their private keys and so what oracles should do is they should just have pay to pub key or pay to pub key hashes on chain and so now i'm gonna go over to mount gox's like funds and just take them as as like repercussions for for me losing all of my funds this is this could be built in uh yes it's it's actually it's not that it can be built in i can't think of a way that it can't be inherent to the system the signature so like

mount gox does not necessarily have to i don't know what the correct word is here if it's like stake funds bond funds like i don't know public escrow fund publicly stake funds they don't have to do this but we think probably with oracle schemes it probably they're incentivized to do so because why would i use your oracle if you're not staking funds and someone else is yeah um and and so essentially what it does is all of these are away when you're reasoning about oracles they raise the cost of bribery right you want the cost of bribing your oracle to be much higher than the amount of money tied up in that oracle right and so all of these ways splitting it up amongst different oracles lowers how much you get by bribing an oracle right uh having this non-equivocation

built into it means that it costs a lot to lie in certain instances and uh there are other things you can do as well some of them get quite complicated and involve meta oracles which you know are reporting on the oracles you can also just have your normal like reputation systems and uh these kinds of things but it seems yeah it seems like a lot of a lot of people talk about them and no one wants to implement one yeah but it seems like this the oracle problem's been uh complicated more than it needs to be yeah i mean at a high level all it is is you have to find somewhere to put your trust and you've got to find some way to mitigate that trust you know i thought like you actually explained that pretty elegantly of like you know spreading

your trust either very thinly across a bunch of people or you know maybe across a few people but you have more trust in them like it is a trade-off and again we are not trying to say in any sense that like this is completely trustless like they're we are trying to mitigate trust when you use this we're trying to mitigate trust but we cannot uh extinguish it yeah yeah i think that's impossible gentlemen uh p break yeah yes sure yes please okay i'm gonna pause right now we'll be right back all right p break done it was great it was a good one and then we had like a little much needed we had like another 20 minute conversation after the break we've got like three hours worth of content uh only an hour 45 recorded so far but i feel like we've been chatting

yeah too fast i feel like probably a lot of it was very dense content so thanks that's good no i was actually thinking of this as you guys were describing everything we ended on uh oracles there but i've learned the most uh from this conversation that i have in a while on this podcast yeah i mean i like to think we are thinking about uh i guess longer term stuff and and stuff that can be, you know, practical in the short, shorter term. Um, you know, one thing I guess I wanted to touch base on with the DLC stuff is again, we're trying to make this specification that anybody can follow. Um, you know, putting out transaction formats,

kind of being thinking about this like we think about the bolts. Um, we're working with a company out of Japan called crypto garage and, uh, they have actually executed some DLCs, uh, with block stream and skew with different kinds of financial contracts. So you can go find that if you want some like real world use cases of like what these DLCs have been used for already. And yeah, and they're working on implementations as well.

So we're kind of parallel working on implementations and then collaborating on specifying things. And again, like the longterm goal of the specification is as with any protocol, I think it should be, have the goal of lifting it up into layer two off the chain. Like we should only revert to the base layer when things go really wrong and we need to settle dispute um in the happy path uh there should really be nothing happening on

especially since the actual uh server-side oracle stuff is layer agnostic like might as well specify that and so this is the point i wanted to get to after all that oracle talk has been my thesis about bitcoin for a while especially in the overarching landscape of bitcoin and everything else is everything else is trying to uh build things that bitcoin is quote-unquote unable to do or support but I've always said like over time this stuff will come in either the protocol or second

or third layers and it seems like it's happening like do we need a world computer with its own scripting language that executes this on its own blockchain? Maybe in a future in a future TFTC session we can go into some

conspiracy theories of mine Sjerdvits research we'll call it that Nadav may have a blog post out on this pretty soon. My bold claim, which I won't back up here, is that if you have a solution, quote-unquote solution, like if you have some black box for the Oracle problem, which is currently needed for anything you want to do on any fancy blockchain that's out there,

then you can do anything that's on any fancy blockchain out there without the fancy blockchain. Let's dissect that. Seriously. yeah I mean so at the I'll keep it short the basic like dumb way of doing it is just like pure escrow like if you have a nice way of like distributing your trust amongst a couple different trustworthy escrows with the right incentives with the right punishments with the right trust mitigation in the same way that we've been talking about oracles then you can do like a two of three

multi-sig with another party and again you you hide the fact that it's a two of three multi-sig so that the escrow doesn't know it's been used or you can even you know do like a five of seven where it's us two and then a three of five escrows or something like that but anyway so you do like a two of three where it's me you and an escrow and like if we're cooperating cool and all that can happen off chain of course and if we're not cooperating either one of us can unilaterally go to the escrow show them our commitment to like a contract written in c++ or whatever language you want and then they can sign off on it and so if you have a way of solving the oracle problem you don't need a blockchain to enforce contracts you only need a blockchain to enforce like digital

signatures and the movement of funds from one place to another it seems more scalable that way too it kind of does yeah especially since all of that can happen off-chain in any cooperative case yeah and there's a lot of people who think otherwise so you need to do it all well i mean it feels like i mean if you're like what we're doing right now where we're like executing dlcs on chain like obviously that's the first place to start before we go off chain with anything but it kind of feels like going to the grocery store or someone this isn't my line it kind of feels like going to the grocery store with like a bulldozer and being like give me my groceries And they're like, yes, we want to give you your groceries.

You're paying us. You don't have to bring your giant, like, tool to facilitate this interaction. Yeah. Yeah, it seems clunky. Totally. And that's, I mean, that's why DLCs were proposed by Tadge, right? To do it in a more scalable, private way. Yeah.

Yeah, and these two of three escrow things have been thought out on how you do them using PTLCs and a certain blog post and mailing list post that's out there. The mailing post is not mine, but the blog post is. This is Z-Man? Yeah, so this is Z-Man SCP-XJ's idea.

You memorized it. It's always, Matt and I always try to do it on the go. Oh, yeah. Z-Man, X-C-P. Z-Man, SCP-XJ. X-C-P-XJ. It's Z-Man like Z-Man,

and then SCP like server copy. it's a command and a command line scp and then it's just xj you just like x sub j it's a normal math scp if you look at it enough you yeah if you uh nice capitalization in there so if you're on the mailing list enough it just happens and this is the uh it's the emails on the lightning mailing list or the bitcoin dev both so the the one on bitcoin dev that i'm referencing with this two of three escrow stuff is called smart contracts unchained uh and then he wrote aka ethereum considered unnecessary or something like that i forget uh and then he's a savage after that there was a post on the lightning dev mailing list about taking it off of uh off of the uh base layer and

just entirely onto payment channels z-man seems like a beast yeah that that man is a very productive guy his and now he's his lightning conference talk was hilarious he's full-time by a square yeah i'm like god like how are we ever going to keep this guy was doing this part-time how are we ever going to keep up with him like he's on every post on the not every but most posts on the mailing list that guy is so productive but one other thing that i guess we're currently drafting is basic like logical structures like ands and ors using for payment points for payment points yeah which is i think it's fascinating because it's starting to get back to like you know basic like how how we represent basic computation stuff is like ands and ors it's kind

of like how we you know a circuits design and specifically he's referring to like ands of points is just like adding them together and then ors is doing these like fancy secret exchange stuff that you can do with points as well which i am not going to have time to to talk about today but i am writing a blog post active area of research but like if we can actually get this right i think that starts thinking is like okay do we have this general computational model then if we can start like representing these things here i think i think the question the a good point to take away from what you're talking about is that although we could just be using two of threes with a bunch of escrows and that's like in my mind like a proof that all you need is a

solution to like the oracle problem to do anything that would require an oracle um that doesn't mean you should be doing that and like that there are better ways that uh have all sorts of like privacy properties and so on and so forth that can go completely off chain be interoperable not not just interoperable with lightning but like indistinguishable from normal lightning activity and stuff like that uh which is an active area of research and of course we can't really implement it today which is why it's just an active area of research but hopefully someday you know we'll pull dlcs up onto lightning we'll pull all sorts of stuff uh into lightning and most of it will just look like normal lightning which is already really private it's just gonna take time freaks

why are people so fucking impatient because i want it now right they do though it's like it's so cool people think it's all gonna come out of the box so like how that just logically doesn't compute uh well at least we don't uh i feel like we kind of under promise and over deliver in bitcoin and not over promise and deliver nothing like some other chain so yeah throw in some shade sorry guys um no that's one thing actually somebody uh brought it up at last i don't even know who's lap last bit devs or somebody said it on twitter somebody's asked like uh like does the price reflect it might have been matt corral on this podcast actually does the price reflect like the development progress to date and people uh somebody i forget who it was does it or has it

ever what's the question like the question is like does the price reflect development progress like the the utility of bitcoin no you think it's under oh oh i see what you're saying i thought you you're asking like does the movement reflect movement no no because it correlated no and this particular person again i don't know who i can't remember who it was said like if bitcoin was uh like orders of magnitude the price was orders of magnitude higher probably would be too high and wouldn't reflect like the pace of innovation happening like we're pacing nicely with the price right now at the protocol level which i feel like uh like development price discovery takes a while so yeah oh it's going to take quite a while i think it would be more

interesting relative proposition like relative to other chains like uh where where is it at like rather than just kind of like this absolute one of is bitcoin price where development is in bitcoin itself or index it against yeah like because like you got something to compare it to it's really easy to do a controlled experiment on because i can just fork bitcoin call it an adobe coin and see what happens it's happened many times i just want my own coin no joking it's uh it's it's actually quite shocking how many people have fallen for that i thought that it would be successful more speculation um so big thing in 2013 bull season was altcoins big thing in 2017 was icos in 2021

what is the big thing that's like this like scam people were saying IEOs but I don't think that's really going to be as big I don't know I was kind of leaning towards stable like not the stable coins you necessarily have out now because I think for most part

central bank coins I think it's going to be shady stable coins with like oh you're going to get this yield on the stable coins like deposit in here things kind of of those already here with like maker credit coins

that's the thing these scammers are running out of narratives I think their creativity is boundless right maybe it's like the DNS and

distributed compute right was that handshakes out right now people are getting all horny the shit coiners are at it again like a DNS system improved DNS system with a blockchain

with a token which doesn't make sense to me I don't know slide into Marty's mentions and let him know what the next scam is going to be at him I get asked that question a lot but honestly over time

the seven years I've been studying this space more particularly the last two and a half three years three years almost i've just decided to focus on bitcoin because like i've learned throughout time that like it's you do waste time wasting mental energy on that stuff and worrying about it and just heuristically over time focusing on bitcoin as a better uh better uh use of my time like that's why i only write about bitcoin only talk about bitcoin it's not worth i mean and not to say i'm not intellectually curious or or that i am just uh narrow-minded i've just been i've just

seen i've been burnt personally and i've seen too many people get burnt it's like all right until something is like uh obviously better which i doubt will will will happen i gotta it's not worth allocating time to in my opinion yeah maybe especially if you're not interested in like some really high level application layer stuff because I feel like that's where we're building out our solutions to our Oracle problems in thoughtful ways and that kind of thing

but that does mean that we don't get around to tons of various user experiences and application layer stuff that we will get to eventually that uh you know is easily done poorly elsewhere yeah no there's an order of operations to this thing too like and um yeah and they're yeah it always i get a little confused when i see like people who have their own coins i won't name names but like go on podcasts or interviews in general or you know record videos of themselves in which they refer to their thing as an experiment but

their thing has like billions of dollars in it or whatever and i'm like someone's being misled here like it's okay to experiment and i'm all for that plane is in the air though but yeah yikes yeah i mean no that's what i've stopped calling bitcoin an experiment and that's why i'm bullish on defi i mean i am but that's not why i'll start gone recently which you know he's kind of a hard advocate for things like side chains which is the original goal of side chains was to allow experiment without uh redoing the monetary network effects of bitcoin but yeah i mean various reasons that's why i'm is like keep it simple stupid as long as we get sound money in the digital age like that's a big enough endeavor in itself like everything else is just extra and bitcoin has the

best shot at doing that the the one downside of not being able to just hard fork is it would be so nice if we could just take a year to like polish the bitcoin like code bases of the world and like get rid of all of our off by ones that are part of like consensus code and stuff like that but that's a pipe dream and i would say i'll just live with the grime it's fine like people liked star wars because it looked lived in so well no that's the only like bitcoin's imperfect like a like a lot of these competitors want to create a perfect system i just don't think that's going to happen yeah and they're lucky to have people like uh russianovsky uh doing the hard grunt work to sort of separate that stuff and make it a little easier right yeah um it just

takes time yeah russ is a legend russ if you're listening to this which i highly doubt russ has a life and like you know like it's a normal person just works hard on bitcoin all day goes out probably walks his dog or something yeah well thank you for doing what you do if yeah seriously um gentlemen we've been crushing this for more than two hours now what uh do you have any parting notes for the freaks out there anything you want to touch on anything yeah um i guess another thing i run is chicago bit devs um so if you're in chicago and listening to this uh we are actually just going to a new location thanks to the loyola folks specifically adam Patel is helping us

organize that. So if you're technical in the Bitcoin community in Chicago or want to learn more about how Bitcoin works at a low level, come hang out with us. We do our best to replicate the excellent BitDevs you guys have here in New York City. We're spoiled.

Everybody should come out to New York at least once and go to New York City BitDevs because it is an experience. We don't have a BitDevs out in Boulder, but we do have essentially a weekly meetup and also occasionally I like throw a workshop together or someone does something cool so come to that if you're ever in Colorado thank you for doing that and thank you for starting the Chicago bit devs because

my experience in Chicago has always been blockchain not bitcoin yeah we're hopefully we're going to change that you know we've been going about seven or eight months now so we're still getting off the ground but you know we got 10 to 20 people that regularly show up so you know we'll never be as big as New York but we've got that core group which is the hardest thing to get frankly when you're starting a meetup so yeah and don't uh don't count out uh hitting parody with the new york bit devs at some point you'd be surprised i get uh i've been going to bit devs since 2015 or 2016 um no and that core group is is essential yeah um so any freaks in chicago make sure you check that out and then uh otherwise uh obviously

the company's showing Shredbits on Twitter, Shredbits.com. Is there any code review that can be helped with? Anyone who wants to contribute to the discrete log contract spec is more than welcome. Come join our Slack and chat with us, email us, post PRs, post issues. Bitcoin dev mailing list, we're there. I will personally respond, and I will not be mad at you or judgmental or anything.

You can just help me with some of my work, please. Thank you. Well, gentlemen, thank you for building short bits and helping Bitcoin out. This was, again, I learned more than I have in quite a while on this podcast. Yeah, hopefully it was good and we can do it again sometime

and hopefully we'll have as much information as we did this time. Well, we'll find out if it was good tomorrow when we post it. I'm pretty confident it will be. Again, thank you guys for doing what you do and for swinging by the studio. Thanks for having us.

Enjoy BitDevs tomorrow night. I'm not going to make it. Send my best to everybody. peace and love freaks