Kevin Whitmore: Kia ora koutou. Very happy to have Lisa aka Niftynei joining us today. So this is a bit of a, a new thing for us. So we've got a bit of a hybrid going. So we've got Jeff's AUT class with us today to, to listen and learn and, and also members of the Web3NZ community and Callaghan's, I guess, broader, broader community as well.

And then we've got Lisa from Base58, so we're kind of doing a combined three, three organization kind of session today, which is really exciting. And yeah, just really excited to, to learn and listen and participate in today's session and hopefully we all, we'll kind of get something out of it and, and yeah, so all good.

So I'll hand over to Lisa. And Lisa, I think today you were keen to, to mostly present, but in terms of questions and things like that, we'll just, we'll just leave it over to you in terms of how you want to run that.

Lisa Neigut: Okay, great. Yeah, that sounds great. Cool. So can you guys hear me okay? Try sharing my screen here so you guys can see everything.

Let's go. How's that look? Okay. Great. So as Kevin mentioned, I'm Lisa, I run Base58, which is a Bitcoin protocols pool. I'm also on Twitter. So if you want to follow me or chat with me later, you can find me on the internet at niftynei. Yeah, so my plan for today is I wanted to talk through the Lightning project.

Kind of talk about how Lightning works at a technical level. Some of the interesting spec stuff that I've worked on, maybe we can get into that. And then at the end or near the end, Kevin asked me, you know, in base 58, we see a lot of people with jobs and kind of like, what is the, you know, what is like the experience of working in Bitcoin as a software engineer, or maybe as more on like the project side or whatever, you know, kind of what does that look like? What are the job opportunities? That sort of thing. So cool.

Lisa Neigut: I thought maybe I would go ahead and get started sort of by giving like a kind of high level overview of like kind of how Bitcoin, what, you know, start with like, okay, what are Bitcoin transactions? Sort of look at some of them on chain, on a block explorer and then start talking through like, okay. How does lightning work? Why lightning? Etc.

I've got a pretty old presentation from ages ago that we can look through kind of walk through that as sort of a high level of the different parts of lightning and kind of how they work. But before I get into that, I think I really want to give like a good background understanding of of kind of what the problem is and like How the blockchain looks?

So if you haven't been to mempool. space before maybe you guys have looked at this a lot already. I don't know kind of what you guys level of usage is of Bitcoin, etc. But this is a really great website, I think, for looking at, you know, Bitcoin information, Bitcoin blocks, Bitcoin transactions Just because they did such a great job with the UI, I think.

'So what we're looking at here is the blockchain, right? So blockchain is a series of blocks. Every block in the Bitcoin blockchain contains a set of transactions. Each of those transactions has like a size, etc. So we can click into the most recently mined block, which is here. It's got some kind of interesting info between like what they expected to be in the block versus what's actually in the block.

This is kind of useful for looking at, at transactions that maybe the miner included because they wanted them. So this one in blue, I think. If it's highlighted in blue, basically, that means that the miner added it because they wanted it. That's kind of what that means. It's why it's got this little, like, added in the audit status thing.

Lisa Neigut: Okay great. So, great. This is a block. These are the transactions in it. You can see how big each of the transactions is by bytes, kind of in this picture. But I want you to kind of think of And the way that I think of Bitcoin transactions is I think of them as documents, right? So each one of these is like a document, kind of like you might get by what do you call it?

I don't know. Maybe you've heard of like paper checks. Let me go open up a a great that worked. Okay. Then presentation. Can you guys see this? Okay. I don't know if this is. Yep. All good. Okay, great. So one way that I like thinking about Bitcoin transactions in particular is of I think of them as like kind of like documents.

So like a paper document or maybe like a Google document sort of even. And they're not, just like, most Google documents maybe are a bad example because a Google document is like a free form document, right? What does that mean? A freeform document means that if you go to like, I don't know, I don't know how to open up, but if I go to docs.

I'm kind of worried I'll open up something I shouldn't, that's fine. So if I just open up a blank one this is like a freeform document, right? Like I can write whatever I want in here. I want in here. Hopefully I don't fill my laptop by opening too many apps, but okay, so I can write whatever I want in here.

There's no structure to it, et cetera. Bitcoin transactions maybe are a lot more like paper checks, right? So if you open up like a paper check a paper check kind of has a format of. Like fields, right? It's got like a set state of fields you have to put information in, et cetera. So Bitcoin transactions look a lot more like forms than they do like paper documents, right?

But they've got like, they've got information in them and it's structured information, I guess is kind of like the idea that I wanna like make sure you understand before we start getting into lightning, because this is actually like, I know it's like, okay Lisa, how does this have anything to do with Lightning?

Great question. The reality is that the Lightning is gonna, Lightning has to do with these forms that are Bitcoin transactions. It relies on them very heavily. So I think it's like a good, it's pretty good. I think if most people have like a decent understanding of like the Bitcoin transaction as like a document, right?

Again, so like the, the fields that it has They're pretty standard. We can walk through them really fast. You can see them here on mempool. space. I'll write them out really quickly because that might be a little bit easier to see. So they are a form document with a set number of fields.

Those fields tend to be there's always a version on the document that makes sense. So what, what fields are on a Bitcoin transaction? There's always a version number. There's always something called a list of inputs. These are Bitcoin that are being spent, oops, that are being spent. And then there's a list of outputs.

These are Bitcoin that are being created, so to speak. And then there's always a lock time. And this is a sort of how do I explain it? A lock time is kind of like a it's sort of like putting it, it's like, sort of like if you have like, so if I go back to that paper check idea that we had over here, I have a picture of a check here.

On the check, you have a date field, right? Sometimes people used to write checks that would only be valid on a date in the future. A lock time field is alot like that. So this is like a date at which this document, right, because Bitcoin transactions your document becomes valid or able to be included in the block.

Cool. So what is a block then? A block is a collection of these forms. But it's a specific collection of the forms. It's the forms that the miner decided to include, decided to include that, that time. So the miner kind of gets, so if you kind of think of it, I think the way I think of the Bitcoin blockchain on a whole is kind of like you've got a bunch of people that want to make a transaction in Bitcoin.

They kind of like go to the nearest, like, I don't know, Bitcoin transactions form person handing out forms for bitcoin transactions, they fill in the information on the Bitcoin form. And then after they filled it in, they go in, they submit it to their nearest miner friend or all the miners. Hopefully, the miner is going to look through this like stack of transactions that they've got.

They're going to sort them around and be like, which one pays me the most in fees? Which one of these belongs to my friends? Are there any of these transactions that I think really like that I personally want to get in the next block for whatever reason? Those are the ones that they choose to put into a block.

And then the block is kind of like putting a big stamp of approval on all of those transactions. And once a transaction gets basically that stamp of approval. or inclusion in a block, it's considered a payment, right? That transaction is considered by everyone on the network to have occurred. So, until they actually get included into a block, those transaction documents are really just proposals, right?

So, until inclusion in a block, a transaction, oops, A transaction is just a proposal. Proposal for movement of funds. So someone's like, Hey, I'd like to pay. So for example, be like, okay, Hey, I want to pay, let's save five Bitcoin, five Bitcoin to my friend, Bob. I'm going to write up a transaction that spends inputs I own and creates a new, and output, which pays Bob. worth 5 bitcoin. I'm going to send that TX to a pool or to the Bitcoin network via the relay network that is includes mempools, etc. Eventually it'll end up, eventually a miner will get it and they'll include it in a block.

And a block at some point, maybe you have to wait in line, maybe you get lost in the big stack of transactions that everyone has sent to the miners to be included in a block, and it never ends up in a block but let's assume that your transaction ends up in a block and that makes your transaction final, right?

Or actually, like, your transaction actually happened, right? But one thing I want to, I want you to notice here is at any point, anyone can write up Anyone can write up a transaction at any point, right? So you can write up transactions. And whether or not you send them to the blockchain kind of depends on whether or not you want them to actually happen, right?

So I could write up a transaction today that says I'm going to pay five Bitcoin to Bob, that maybe I set the lock time to like a week from now. So I could make that transaction. Send it to Bob, make it a valid transaction. One way that we make transactions valid and in Bitcoin is by signing them.

So I'll make a transaction, I'll write up kind of a check, I'll put my signature on the check, I'll send the check to Bob, but Bob won't be able to send it to a miner, because a miner won't include it until the lock time has passed like five days from now, right? Okay, so it's kind of like, Sort of like a new way of thinking maybe about Bitcoin transactions as like documents that we put information in about our intention of how we want to take Bitcoin outputs that we own and spend them into new outputs that maybe someone else owns.

Maybe we own some of them, etc. Okay, so that's kind of like the pretty heavy, like pretty, maybe the like 30, 000 foot view, so to say, 30, 000 foot view you know, foot's an American thing, maybe you say meter view, 10, 000 meter view of of how Bitcoin works. Great. Okay. What was there's one thing I wanted to kind of point out that I always think it's sort of fun to talk about.

And that's whenever you have like a block so because of these blocks blocks basically make Bitcoin a batch processing, a batch processing like financial system, if that makes sense or financial accounting system, because transactions get approved or included into the set of valid transactions like in batches and that batch is the block. So if we go back to mempool. space, which is I think just really great for being able to see What that batch looks like.

This actual block, the site on the right, this is the batch of transactions that were actually included in a block. So this is the, all of these transactions went from being like kind of proposals to move funds to actually having moved funds as soon as this block got mined, which is pretty cool. Wow, that's a big transaction.

That's a lot of data. Just as kind of like a, I don't know, not really like Important aside, but sort of just been aside, but the little size of these boxes has to do with the amount of data. Like, so the number of bytes that goes into this transaction. So every block, so every block is a batch, right?

Every batch of blocks, so every batch of transactions... Blocks are limited to blocks on Bitcoin. Oh actually, this is a great kind of segue into why, why, why lightning. Blocks on Bitcoin are limited by the number of bytes that they're allowed to include in a block. So every block technically It gets a little, it's like, it becomes a little hard to like, explain exactly, but the maximum number of bytes you can get into a block is four megabytes worth of, of, of transaction data, right?

So as you can see, like some of these Bitcoin transaction forms, so to speak, or like have a lot of data in them, other of them are quite small, but at the end of the day, you can only fit so many of those forms into a batch at a time.

Okay. So why is that important? So we can, we're doing batch processing. The thing that we're processing are transactions. Transactions are data. So they're data and they all have a size, a size based on amount of data in them, in the transaction. And so each batch can only fit a four megabytes worth of bytes. So, okay, so this starts to introduce a problem, introduce a problem I don't know.

Hard to see you guys at the class. So now I would be like, does anyone see where the problem is? I don't know if there's like a chat function. I don't see. I can see the chat function. That's a thing. No. Okay. That's cool. Great. Okay. So hopefully if you, if you look at this, if you look at this picture the problem is that There's a lot of transactions that want to get mined, right?

And you can only fit so many at a time. So this means that if everyone is transacting with Bitcoin or on Bitcoin not everyone is going to be able to get their transaction in, in a timely manner. In fact, this is where mempool. space, I think, is really cool. You can see all the blocks that have been done.

Everything to the left of this line are proposed transactions, basically transactions that want to be included in a block. These are all the transactions that already, these like all the blocks that exist. If we scroll all the way to the left, mempool. space only shows us the first 1, 2, 3, 4, 5 ,6 ,7 ,8 blocks. When I view that over here, there's 130 extra blocks worth of transaction data that's just sitting basically in like the miners inbox, so to speak. All of the miners are like currently sitting on 130 plus worth of trans blocks of, I'm sorry, 130 blocks worth of transaction data that they're just slowly getting in every 10 minutes. Right?

Lisa Neigut: So I think maybe that's the other that's another thing to introduce here to the, to the picture. Is the fact that Bitcoin is set up such that a new block only happens every 10 minutes, which is kind of insane when you think about it. Like there's only like, I don't know how many, how many transactions are in this block. Does it say how many transactions there should be a transaction count?

There's 2658 transactions in this block. So if we divide that by 10 minutes, I don't know, can we do math? Let's do some math. How many transactions was that? That was 2, 600. Wow. How come this is a different number than this number? No. Oh, this is this number. I see. This is the actual number. This is the proposed thing.

This is what actually happened. Okay. So 2, 649 transactions went into a block. So that's the number of transactions. And if we divide that by 10 minutes times 60 seconds, you end up with, wait, hang on. My printer's using the right spot. We end up with about 4. 4 transactions per second. If, if this last block, so if the last mine block just right now is a indication of the throughput, so to speak, of Bitcoin at the base layer it's telling us that we can do 4. 4 transactions per second on average.

Now, obviously, as you notice, this block has some really big transactions in it. So if you know, if you took like the smallest version of it, you could maybe like double or triple or I don't know. I'm just kind of looking at it by size. You could probably get more transactions in, right?

But at some point, though, at some point, at some point, there becomes a question. How do we scale? How do we scale Bitcoin?

Great. So like, there's a few things, right? Like, and then this was like more of a question or a problem back in late 2015 to late 2016, which is around the time that Lightning kind of came out and started, people started working on it started getting work done and proposed. I think the original lightning white paper came out, I want to say in like January 2015, we can go look it up here in a second.

Okay. So again, so this is kind of an older question. So the couple of ways that were kind of tossed around back in the middle of the 2015 2016 era was that they they started saying, Hey, okay, what if we made the blocks bigger? Or, what if we could make payments off chain I'm trying to think if there were like any other big proposals.

I feel like they're making the block bigger, or, or we could make what if we make the blocks more frequently. What if we just had blocks, like, arrive faster than 10 minutes? Like, if you had blocks, if you made a new block every 5 minutes, what about just 5 minutes, right? We could 2x, so we could, we could easily 2x the throughput of layer 1 just by making blocks come faster than every 10 minutes.

If we made the blocks bigger, we could fit more, fit more transactions into it. So there's a re there were a couple of reasons why these first two suggestions making the blocks bigger or making more blocks come more frequently are like slightly problematic.

Like, does anyone know why these things are slightly problematic? I'll let you think about it for a hot second while I search for how to get zoom to show me in the chat, just in case, yeah, okay.

Kevin Whitmore: You can write that on the chat if need be. If anybody want to post, wants to post in the chat, just pop it in there and we'll read it out.

Lisa Neigut: Okay, great, yeah.

Kevin Whitmore: So we've got breaking consensus. There's a, there's a question, and then increasing the block verification processing time, too many forks.

Lisa Neigut: So here's some proposals that we were getting, proposals too many, I have it open up here too, too many forks. Breaking consensus. Increased node and bandwidth requirements.

I feel like there's one more here I'm missing. Increase block verification processing time. Okay, can't run a node on a, can't run a node on a Raspberry Pi. Okay

I got one more. Okay, I think that's, I think we've got a good list there because Satoshi says that's not how it is. No. Okay. Okay, so let's consider these really quickly. So breaking consensus, I think this one would need. Alright, so let's like talk a little bit through at least my understanding of how it is.

And I think you guys maybe can then map that back to map that back to the proposals we got from the chat. So yeah. There's a few things here that are going on. I think one, as it was pointed out if you increase the block size, that means that there's going to be more, so, okay, well, hang on, there were two things that we, we looked at.

There was increasing the block size, so let's talk about why that's difficult, and then increasing the frequency of blocks, basically. Frequency of blocks. Okay. So if we increase the block size, this means that now, so if we have, let's say we just double the amount of space in the block. So instead of having four megabytes, well, technically back in the day, it was one megabyte before Segwit, Segwit increased it to four, sort of.

This is where I get kind of cagey about it. So I'm like, yeah. Sort of. It's like hard to explain. So there we did do a block size increase with Segwit. But what like, so what are some of the downsides of that though? Obviously it means there's more data in the actual blockchain. Which means Bitcoin is probably one of the few like blockchains in existence where everyone who runs a node is is able to have an entire copy of the entire blockchain, or at least that was one of the I would say, like, some of the design goals of Bitcoin.

Lisa Neigut: So maybe these are good to keep in mind while we're talking through this. So the design goals are that it, the decentralization, decentralization continues to be possible and feasible, be feasible. Everyone every man, every man can keep a copy of the Bitcoin blockchain, so basically you wanted to be able to people to run it on sort of like commonly available computer hardware, didn't want to make it such that you needed to have access to a A big what do you call it?

And I'm going to cough. Excuse me. Sorry. Okay. I'm okay. Every person needs to be able to kind of keep a copy of the Bitcoin blockchain. And it's kind of going along with that is someone mentioned about verification. Everyone needs every man can verify a copy of the Bitcoin blockchain.

So, kind of like every man, I guess I should say. Every person's fine. Every person like cool. Okay. Every person can keep a copy of the Bitcoin blockchain. You can also verify that copy. So keeping a copy of the Bitcoin blockchain takes up space. So we need like memory, right? Is that the right like disc space, space.

We got disc space that you need access to hard drives or drives of some sort in order to keep a copy of the Bitcoin blockchain. And then depending on the verification requirements, doing a verification uses some CPU, right? So you basically need access to, access to some, some compute power, right?

In order to verify every transaction because the thing about Bitcoin is that every transaction that ends up in a block gets verified by every node on the network, right? So the inclusion of a transaction into a block Basically means that every single node that's running on the Bitcoin network is going to need to be able to one get a copy of that transaction and two execute any of the Bitcoin scripts that are included in it.

So that's kind of a maybe a side note, side note inclusion of a transaction into a block means every node on a network needs To get a copy of it, right? And so that takes time. So that takes and every node needs to validate it. So that means execute, execute the scripts contained within it. And every node needs to get a copy since there's some bandwidth requirements, right? Bandwidth, whatever.

Another thing that you need for everyone getting a copy is you also kind of need some time, right, for propagation. Because in Bitcoin, it's not like all of the nodes like listen to one single center master node, right? Remember decentralization is a really big, important part of what makes Bitcoin successful. And we need it. We need Bitcoin as a, you know, kind of one of the design goals is that we don't make any technical choices at the protocol level that make it such that you can't can't that the network becomes centralized, if that makes sense.

So I think kind of maybe looking through these, these design goals and some of the kind of side effects of including a transaction in a block. Suddenly, you need to make sure that also one of the things about the block is you also need You also need every block, so you need, need time for blocks to propagate so that miners have enough time to start looking for the next one, next winning block. Because in order to build a winning block for the next round, you need to know which transactions were included in the last block, so that you make sure you're not trying to include one of those already included transactions in the next block.

If you do that, the block that you make will be invalid, right? So. You want to make sure you have the last block and the list of transactions in it before you start working on the next block. Also, you need to know the hash of the last block in order to include it in the block header of the next block, right?

Because that's what makes the Bitcoin a blockchain is that the hash of the previous block is included in the hash of the next block. It's kind of how you chain them together. Right. So you need time. Okay, so there's a couple things going on here. We need time to propagate all this information for a couple of, you know, a couple of both for the nodes that are just holding and storing and verifying the data, and also for the nodes that are looking, they're mining, they're looking for the next block.

You need to make, we need to make sure that we're not sending out too much data too quickly. Also, because we don't want to start filling up people's hard drives, right? So if we start if we make the blocks bigger, or if we start sending blocks out more frequently, all of a sudden the data storage requirements for keeping the Bitcoin blockchain and having a copy of it starts growing a lot faster, right?

So it's kind of a speed at which the blockchain grows really depends kind of on, again, size effects and how fast blocks are coming. So keeping the size small means that we make it easier for Anyone who's a bitcoiner, anyone who has a laptop to run and keep an entire copy of the of the chain.

And then again, yeah, so we don't, we don't send blocks out as fast because we want to make sure there's enough time for all the data to propagate both for the miners and for the people who are keeping them. Okay, I feel like I already said that stuff.

So I think that, like, I think you guys kind of covered a lot of it the, the block verification processing time would go up in the case of more bigger blocks, right? So this would increase the verification time All things being equal. Can't run a node on a Raspberry Pi would probably be, I'm guessing, the data storage. So this would be faster blocks, maybe, and bigger blocks, right? Because those both grow the total amount of storage needed quite quickly.

Satoshi I don't know if it's Satoshi. I mean, Satoshi definitely outlined the original parameters that The Bitcoin blockchain follows, so to speak. But I don't think he was like necessarily, I don't know. I'd have to go back and look at the white paper again and maybe see what he said, but You're right, they wouldn't, changing the parameters would be different than what Satoshi set us out to.

Too many forks can happen if blocks come too fast. So this is a faster blocks problem. Ethereum has this actually it's kind of fun, I think just to sort of, so I'm going into a lot of asides, but it's fine. I'm gonna keep doing it. The Ethereum network so Ethereum as a blockchain was designed and built and shipped.

I want to say almost like, oh, I'm going to get these numbers wrong, but like three or four, maybe even five years after Bitcoin came out, right? So a lot of the design decisions in Ethereum are sort of reactionary to the ones that Bitcoin made. Some of those, one, I think a really good example yeah, one of the good examples of I think of kind of how, you know, Bitcoin was the yin, yin, and Ethereum kind of yanged the other direction is that they do 15 second blocks on Ethereum.

I think that's on average, that's kind of what they target. And then The other thing that they do that I always thought was kind of interesting oh, I don't know if they have like a block size. There's a lot of kind of interesting differences between Ethereum and Bitcoin. But like, I always think, I don't know, the 15 second block one, I feel like it's a really big kind of like.

You know, Satoshi's like, we're going to be very cautious and we're going to give you 10 minutes to like send all the blocks everywhere in the world and give people time to verify them. And then to you know, for miners to start working on the next block and Ethereum is like, ah, that's fine. I didn't really care about that.

15 seconds is good enough for anyone. Right. Okay. Ethereum is also kind of notoriously difficult to keep an entire copy of and scan from the very beginning. And I think the fact that there's just a lot more data there on the chain is one of those reasons. So they definitely, I don't think Ethereum had as a design goal kind of this one that everyone can keep a copy of the Ethereum blockchain, which is fine.

Like they just picked different design goals. And, you know, I think the systems. Your different design goals lead to different architecture choices and different architecture choices lead to different problems later down the road. Bitcoin now, of course, had, okay, so what we ended up doing is we didn't increase the frequency of blocks.

We didn't, we ended up kind of doing a block size increase, like what was a, I call it kind of like a sneaky, sneaky block size bump. And the reason for that is that it like kind of went from one to four megabytes, one to four megabytes which ordinals kind of take. Anyways, that's like, that's like a detail I don't want to get in the weeds.

Okay, let's get to lightning though. Okay. So changing the amount of data in the blockchain was kind of like something that we definitely, I don't want to say definitely didn't want to do, but like really wanted to avoid doing. So instead they're like, wouldn't it be great if instead of having to keep, and the other thing about like having to put all this Bitcoin transaction data into the global ledger, is that like, okay, imagine a situation where All of us.

I think there's maybe like, let's guess 40 or 50 people on this call. Imagine all of us are like hanging out at someone's party and I want to buy a beer from, or I don't know sparkling water from from, from, I don't know, like the bartender at the party or whatever. So I walked over and, you know, with cash, I would just hand them like a 5 bill.

But Bitcoin, when I want to like pay a bartender for a beer I'm going to pay them five Bitcoin for a beer. It's the most expensive beer I've ever bought. So I would make, you know, I'd write up my Bitcoin transaction on a form. And then the way that Bitcoin works is in order for that Bitcoin transaction to be considered valid, it has to like, One, get inside of a block, right?

So I write up my transaction, I go give it to my nearest miner friend, who also just so happens to be at this party they get to work trying to get it into a block for me, that's very nice of them, while all the rest of us are partying and then after, you know, maybe 20, 30 minutes, they succeed at producing a a winning block hash so great news, I can now get my beer from the bartender. Though really I should have bought two beers because I already drank the one he was selling me after 30 minutes.

And then what happens is that let's assume that everyone at that party is also running a is also running a Bitcoin node. Now, every person at that party, so to speak, is also going to need a copy of this transaction that I wrote up to pay the bartender. And I'm going to need to send that transaction or hand that transaction to every single other person in at the party, right?

So at the end of the party, everyone should have a copy of this transaction that says I paid the b the bartender, five Bitcoin for a beer. I mean, they won't know what it's for. And hopefully they don't have any idea like what my pub, like what my address was on the blockchain. So they won't know who is paying who, but they'll, everyone at that party needs to receive a copy of my transaction that I sent to the miner

okay, so. This means that like transacting, transacting with Bitcoin on layer one kind of becomes inherently less private, right? Less private. inherently less private. It also means that it's less private. It's kind of just like, I don't know, I would call it information intensive. Like everyone has to find out about like the amount of communication that needs to happen as every new node, a new node hops online or a new transaction happens. Suddenly starts getting like there's just like a lot of data that needs to be flowing. It's just kind of Everyone has to find out about it.

Okay, so, some of the design goals, I like talking about design goals, I think they're fun so some of the design goals of layer 2, so, of layer 2 then is to increase the throughput of transactions, right, of, let me, Okay, increase the throughput of transactions on Bitcoin with Bitcoin, so to speak, so more people can be transacting with Bitcoin, maybe make things a little private or more private.

So I don't have to tell everyone at the party that I just paid the bartender a lot of money for a bit for a beer. And then, yeah, is that it? Increase throughput so you can do more transactions using Bitcoin. Oh, it has to, you know, be with Bitcoin, be using Bitcoin and, you know, maybe making things making things a little more private.

Trying to think if I forgot any. I think that's most of it, though. I think that covers it. And then also, like, not contributing a lot of extra data to the main chain would be nice. Not contributing too much extra data back to the main chain. Okay. Okay, so these are some of the design goals.

Lisa Neigut: Where did we end up? All right, so how does Lightning achieve this? Or what does Lightning do, really? So there were a couple of proposals kind of came out of this idea of something called payment channels. I forget. I don't know a whole lot about like the pre prior art to Bitcoin trans to lightning.

But increased speed of settlement from the chat. That's yeah. Make transactions settle faster, faster, no more waiting 10 blocks, 10 minutes. I think I've done this, which is so nice. Yeah. So now you can actually like buy things quickly and people get the Bitcoin instantly. Wouldn't that be amazing? That would be so cool.

Okay, so there's a couple ideas of like, how do you do this? How do you make transactions settle faster? And the answer is you so kind of the answer, answers maybe. Maybe. Is first and foremost, you stop telling everyone about every transaction. What if instead of having to tell everyone, you only tell the people that need to know, make it a need to know basis?

That would cut down a lot on so that would cut down a lot on the amount of communication that we need to do in order to make transactions happen, right? Instead of having to tell everyone, what if you only have to that would be great. That would make it a lot more like cash, right? Where cash is like a piece of paper that you can just, one person gives to another, no one else needs to know that I handed you five dollars I can just give it to you and that's it.

We both consider that transaction done having that sort of interaction sort of more possible on a layer two would be cool. So stop telling everyone about every transaction helps I think most of these things. I think it helps with the throughput because now you've greatly reduced the amount of information that needs to be like communicated across participants in the network.

It makes things a lot more private because you're only telling the people that need to know about the transaction instead of everyone. So the only people that actually have to even know that the transaction happens are ones that were involved in making it happen. We're not contributing very much data back to the main chain then, because all this data can be kept privately.

There's no more public data, so there's no more data on the chain really for those. And the transactions can settle much faster. We'll talk about that in a second. Okay. Is there anything else? Okay, so how do we stop telling everyone about every transaction, but how do we still make it Bitcoin?

How do we still make it Bitcoin. Okay, so I think, I think that Lightning, the way that Lightning designers, the answer that they came up to this is still sort of best in class and the way that they like decided they were going to do this is like, okay, what if we still use Bitcoin transactions to what if we still use Bitcoin transactions to transact with.

The only difference is so the same form, right? It's the same little like check format that we learned about at the beginning that you fill out and put information into. So we're still going to use those Bitcoin transactions. The only difference is that now we're also going to oh, I'm sorry.

So the, the oh no, I'm getting a little tired. That's okay. Oh my god, my fluency is going down. That's fine. Okay. I'm going to go back to here. So if I take this, I'm going to copy this down to here. So kind of, this was The last, this is sort of the transcript that I wrote of the transaction that we wanted to make happen between two people.

So I want to pay my friend Bob on Bitcoin. I'm going to write out the transaction. I'm going to stop here though. So lightning kind of stops right here. All we do is we write up the transaction that spends the inputs instead of sending it to a miner and getting it into a block. So this goes away.

Now what we do is we send copy of, oh, okay, wait, I might need some more information before we can get in here. I think maybe the, the, like, overall arching idea though that I want to kind of communicate is that we're using transactions now. The difference is these transactions don't get sent to the blockchain.

Instead they get traded between two parties that have a shared account. I'll talk about how these shared accounts get made here in a second. This gets into where Lightning Channels come from. So they get traded between parties that have a shared account and Don't get sent to the blockchain.

Traded between parties that have a shared account. Right. So it's kind of like, kind of like, I don't know, exchanging baseball cards or something. Digital baseball cards. No, that's not really a good thing. But it's sort of like you can basically like handing, handing like paper documents back and forth between two parties, exchanging I'm going to call them updated versions of contracts.

like technical way of thinking about this. But you kind of just, you can keep it at this like paper stack level where we not involving the miners who actually needed to like include it into like a very formal batch rate. Cool. I need to take like a two second break, I'm going to grab a glass of water and I will be right back.

I'm trying to think if there's like a there's something I can make you think about while I'm gone. They get traded to parties that have a shared account. Okay. So I think like, so in order to make this work we need to establish sort of shared accounts. The reason we need to establish shared accounts is that the shared account balance is what we're going to be able to keep track of with these paper transactions, so to speak.

So basically this is like, we sort of like create a create a shared pool of money. On layer one. So layer one, if you think of layer one as like an accounting system, we're basically going to like remove the accounting for a certain set of Bitcoin from layer one and move it into the layer two.

Move the accounting for that shared money. Into layer two. Oops. Into layer two. And then we'll use layer two accounting, which in Bitcoin is un broadcasted, un broadcasted Bitcoin transactions is how are we going to keep track of who owns what money?

Lisa Neigut: Okay. So my like two minute challenge for you then, and maybe you guys will figure it out in two seconds because you're brilliant. Is how do you establish, establish a shared account in bitcoin? Okay. Maybe this is a, I can't tell what's a hard question anymore. It's fine. Okay. I will be right back. I'm going to go grab some water here and I will return very shortly.

Kevin Whitmore: Maybe we all take a bit of a break or a breather, do some stand up and walk around or yeah, we'll meet back in a couple of minutes.

Yeah, we've got a couple of answers that include FTX and third party escrow, so there you go.

Lisa Neigut: Oh, sick. Okay, hey guys, sorry, that took a second. All right, I'm back. Got some water.

Okay, how do we establish this here to chat? Someone says, let's see, we have two of two multi sig, I'll just write these out, so our suggestions, proposals, whatever you call them, proposals someone said the two of two multi sig.

Multisig. What else do I have in here? Shared account give it to a custodian, like FTX or BlockFi. I've heard great things about them. And then paper check metaphor. I don't think that's the shared account via third party escrow, third party escrow and then Elon plans to do with X. I'm not sure.

Great question. Okay, I don't think that's all right. Cool. Okay, so, right, let's go through these. Okay, so I think one of the okay back to design goals seem to like talking about those a lot. So one of the design goals is that one of the design goals of Bitcoin, is that we no third parties, right?

I believe the white paper title was a peer to peer, right? Electronic cash system. I think I might be wrong about that. Someone correct me if I'm wrong, but I believe the original proposal or the vision for Bitcoin is that it would be a way to do peer-to-peer electronic cash. So the idea that you would have to use a custodian or a third party escrow I think those kind of like get immediately taken off the board in terms of designing how this layer two is going to work.

So those are. Those are off the table. Okay. So let's see, what does that leave us with? Oh, two, two amazing things. Okay. So multi sig is in fact, the way that the lightning designers designers, or, you know, figured out you could multi sig is in fact, the way that people decided they could do shared accounts on lightning.

Lisa Neigut: And so maybe you can talk really quickly about how multi sig works. A multisig works. It's pretty straight forward. You get a pubkey, pubkey from each party that wants to be part of the shared account, and then I'm going to save it for the sake of this. I'm going to say that shared accounts have to have like N of N. So if you have N pubkeys. N pubkeys.

You have to get N signatures because otherwise it's not really a shared account if like, I don't know, let's say if you had five people with pubkeys and only three of them, only three of them had to sign. This is also for the record, this is called the threshold multi sig. Sometimes that's useful in considering multi sig constructions.

I would say that this is like, it's a shared account, but it doesn't, it's not the same, right? When you have n of n, like, so if I get five pub keys and I say everyone has to sign, all five people have to sign, this is like a real shared account, right? Everyone in that thing, this is like, kind of like, I don't know what kind of juries you need. Like sometimes in the, in the United States, sometimes there's like in court cases, the jury has to be like in agreement, unanimous agreement in order for the decision to be like final or whatever so they leave them in the room until everyone comes to an agreement about one way or the other.

This is like I would say this is like a true, like shared account, right? Like everyone has to agree about where the money is going. Before they signed it. So kind of, again, like the way that, you know, Bitcoin transactions work Bitcoin transactions are checks or sort of like paper checks or a lot like paper checks.

And one of the things that you do with a Bitcoin paper check is you usually put a signature on it, right? Making a multisig basically means that in order for any check to be valid, any check to be valid, everyone that's listed on the account everyone listed on the account, everyone listed on the account must sign it.

You must sign that check. And what happens whenever you're given a contract or like a piece of paper to sign, well usually you're allowed to take as much time as you want before you sign it, right? Like, no one can, like no one can, like, force you to sign something, right? Usually, when you produce a signature, that signature means that you have looked at the terms of the contract or the paper check that you're being asked to sign.

You've done your due diligence in figuring out the terms of that contract or ones that you agree to. And then, after you've done all that, you've read it, you've looked at it, you've talked to maybe your lawyers, etc. Then and only then do you put your signature on something, right? Bitcoin transactions should be no different and in fact there's no reason to to have them be any different.

So when you may start making these shared accounts that require every party to sign it before it becomes final now you just kind of have a digital way of kind of doing a similar thing that we had with paper. Where am I going with this? The the idea now is that, like, Yes, you need everyone's signature.

So everyone, so by getting a signature from every party on a Bitcoin transaction that is their implicit explicit, I should say, explicit approval for whatever's in that transaction. Okay, cool. So kind of like, I don't know, highlight or note is every signature, a signature on a transaction, section is a like a stamp is an approval, is an approval because it makes And the reason for that is the signature, like in aggregate, you get a signature from every party.

The signatures make the transaction valid, right? So it's kind of a way of making these bullet valid documents. Okay, so why do I keep mentioning like courts and contracts and validity of signatures? Okay, so one of the things that I think is pretty useful when thinking about how Lightning works and why it's designed the way that it is, is it was kind of came out with, I want to say 2015.

We can go look up when the white paper was made. Let me see if I can find. This thing I don't think I'm going to use this thing, so that's fine. We're going to do what was the lightning whitepaper? Lightning Bitcoin whitepaper was written in this one here. This one was, oh, 2016. Okay, but it was obviously talked about in 2015.

Okay. So right. So in around like 2015, early 2016, hand wave fun fact, I got into Bitcoin in 2018 and started contributing to spec stuff as early as 2018. So I came, I got into Lightning two years after So, basically, or, like, two years after the white paper came out. So, I've been in lightning a long time. Okay, where am I going with this? Right, 2015, 2016, there was this idea in blockchain land, and, like, you know, the Zeitgeist, or the hype cycle of whatever the popular thing in lightning was at the time, or in blockchains at the time, and I think this, kind of, I like to think it sort of came more from the Ethereum side of, Thinking than anything though, don't tell all the Maxis that I might get in trouble.

But the general idea was that Bitcoin not Bitcoin, I'm sorry. It's kind of like a code is law was the was the, the pithy saying that everyone was kind of like trying, especially over on the Ethereum side, it was like trying to like figure out what it meant. Now that we have blockchains, the code was law, right?

Like, what did this mean for us? This is kind of where you got the DAOs came from the idea of DAOs came from I don't know. I feel like there were like maybe some other things that happened from this. DAOs are like the only big one I can think of that sort of had any sort of impact. Yeah, but okay.

The other thing that came from this is Lightning. These are probably like, I should probably write like a blog post about this because it's sort of interesting. I think historically DAOs which has been the DAO hack, ETH had its own, ETH kind of went a different direction at this point with this idea.

Lisa Neigut: Bitcoin went towards Lightning, which I think was you know, a good idea. Yeah. Great. Okay, so how does this have to, what does it have to do with Lightning? Where does it, like, what? Okay, so the idea with Lightning is that, like, if you think about, like, paper contracts, so earlier we were talking about paper checks, but now I want you to kind of start thinking more as, like, contracts.

And contracts can have clauses, right? They require signatures. The thing about a contract is two parties can sit down and write a write a contract and they can both agree to it. And they can both act, they can both, they can both like abide by its terms. So to its, so to speak for the life of that contract.

I'm sorry, like and then they can abide by its terms. They can agree to it. And then at the end of the as long as there's no dispute, as long as there's no disagreement. Does the court ever need to know about this contract? Maybe think, you know, I'm going to start talking about law.

You know, I live in the United States. I've pretty much always lived in the United States. So my understanding of how courts work is very American for obvious reasons. So maybe it's different other places, but at least in the United States, when two parties, private, corporate or like private parties draw up and sign a contract, maybe you've signed a contract to lease an apartment. Maybe you've signed a contract to take out a loan.

For the most part, who keeps the copies of those contracts? Those contracts for the most part are kind of kept privately, right? And you only ever take those contracts and send them to the court. In this case, the court is the blockchain, the miners kind of what is valid on chain the courts are on chain.

Are on chain the only things that the courts are going to see are going to be in the you only, you only go to court in the case of a dispute or other issues. Right? So, ideas sit in, like, the happy path. Happy paths are, like, something that I think about a lot as a software engineer. Happy path.

Happy path is my favorite. Happy path is easy one to code. Right? If everything was happy path, I feel like there would be about 80% less software in the world. Right. The happy path, you never have to talk to the court. You can keep a lot of what's going on private. The only thing that needs to go on chain, the only thing that needs, thing that goes on chain.

And maybe this is more like other places where you actually do have to send like an initial version of your contract to some registered party. I don't know. I'm making this up. I don't know if that actually exists. But the only thing that goes on chain is the, is that is the the contract, so to speak, that establishes the shared account.

And then in the happy path, the only thing that goes on chain would be the contract that opens the shared account and then the basically contract that closes the shared account, right? So kind of like pays it out to both of the parties that were in it. And then if you just swap out the word contract for transaction you basically have a very good. That works.

That is still the same statement and that basically very well describes kind of what's going on in Lightning. Okay, it is 8 15. I think I have another 45 minutes. I think I'm going to spend another maybe 20 minutes talking through some more Lightning stuff and then if you guys have any questions, maybe we can do a little bit of question stuff.

And then I will go ahead and get into some of you know, sort of like, what is the hiring market look like for software engineers? What are some of the paths through working on Bitcoin? Like, what kind of work is there to be done? What are some interesting problems? That sort of thing. Okay. Cool. So I have now finished describing Lightning.

I think we're done. No, I'm kidding. We've done the happy path though, right? Okay. So what does it look like? Actually, we never talk about the unhappy path. I might be able to get this done in 30 minutes. Okay. Okay. So what's happening then is that basically two parties come together, together, and they exchange pub keys so they can make a, they can make a two of two output on the blockchain.

This 2/2 output the money in there now becomes part of a shared account. Once you have a shared account, once you have a shared account you need a way, need a way, way to keep track of the balance in it, right in the account. Okay, so we need a way to keep track of balance in the account. The thing that we landed on is we're going to use Bitcoin transactions.

So Bitcoin transactions have inputs, they also have outputs. One of the outputs, oh, oh no. One of the inputs is going to be the two of two output that we made when we opened open the account so that the, we're gonna spend, so these Bitcoin transactions that are held, either held off chain, these are sort of the what I think of as the contract itself.

There's like the, the, there's a Bitcoin transaction which establishes the contractual relationship and then you have a series of contracts which are really off chain transactions that kind of reflect the current state of who owns what in the channel. So, the way that these look, these like off chain contracts or these like updated paper contracts that we keep, each of us is going to keep a copy of them because, you know, there's no central authority that keeps a copy of these contracts now, like the miners or blockchain or the rest of the nodes on the network.

Instead it's really up to the two parties that are involved in this shared contract, in this shared account to keep a copy of their transaction, of their current, the most current like state of that contract, so to speak. So right this is what's in the contract. What's in the contract, in the contract is the output you're spending.

So what's getting spent and the outputs are going to be kind of a list of who owns what who owns what in the channel. So this will be the current channel balances. So if it's me and the bartender, I'll have like, I don't know, let's say I started with five Bitcoin. And then I'm going to pay the bartender.

Maybe the bartender starts with one Bitcoin in this like shared account. So I've had to like set up, there's a little bit of setup in these, right? You like have to set them up by making an on chain transaction. And then you can exchange the amount of money in the, in the account between yourself. By updating the paper contract that you guys have like kind of established of what the current balance is.

Okay, so. Great. This is what's in the contract. We're spending our shared out point. And then we're going to pay that out based on who owns what currently in the, in the channel. Okay, great. So this would be like This is the original contract. And so if I want to make a payment to the bartender how does that work?

Great question. What we do is we take the last contract, we update the the current state of it to say remember I paid five Bitcoin for a beer, so now I am a little poor very poor. So now we would make a new version of the contract, which says it still spends the same output, right? So this is going to stay constant for all these on chain, off chain, I'm sorry, all the off chain contracts will all be spending the same amount, the same account, spending out of the same account, which is an output on the blockchain.

And all that's going to change is like where those funds end up after this transaction or after this contract were to get into a block, so to speak, kind of hand wave. Okay, this is me, this is the bartender. Great. So yeah, so basically what you end up with is every time you and your counterparty, your channel counterparty, as we say exchange funds or update the balance the way that you update the balance is by making, by writing a new contract With different payout terms, I guess I should say, kind of a way to think about it.

And then writing a new contract with different payout terms. And then what was I saying about signatures earlier? Once you get a signature for someone on a new contract, that is basically their explicit approval of the terms in that contract. So the way that you kind of approve what a new lightning channel balance is, is by signing a Bitcoin transaction that spends from a 2 of 2 that you own one of the keys for.

So whenever you make a transaction, the only thing you put signatures on are the inputs, so you would add your signature to the input, and by producing a valid signature for the new version of the contract, that would be, and both of you have to sign it, right? It's a 2 of 2, so you need a sig, so I would need my sig, and then I would also need the bartender's sig, and as soon as you've gotten both of those signatures both parties basically agree, That this is both parties basically agree that this is now the new state of the channel yeah, oh boy, I'm sorry y'all, my head's like, I'm getting tired, it's okay, I'm doing good all right, cool, so.

Right, so every time the bartender and I want to negotiate a new balance, one of us has to write up a new version of the contract with the updated balances and the outputs, and then both of us need to sign off on it, and that makes it a new valid balance in the channel, and we call that, that's how we do, that's kind of how we do, how we do faster settlement.

Settlement on Lightning is by producing producing valid signatures, huh. signatures much, much faster. Oh, you can produce valid signatures much, much faster than you can mine the block. Right. So, and those valid signatures are like, those are immediately spendable Bitcoin transactions. Right.

So as soon as I have your signature on a Bitcoin transaction that I can immediately take to the blockchain and get into a block we consider that in lightning as good as the funds having moved. And so, okay, I can see I'm already getting questions. I've got about, I think like almost 40 minutes until the end.

Lisa Neigut: So maybe should I keep talking? No, I'll answer the questions. Okay so there's two questions. Question one is how do fees work? Question 2 is... Who funds the channel? These are all great questions. Okay, how do the fees work in Lightning? Oh, this is great. These are all great questions. You know who can answer these?

You can answer these questions, lol. I can answer the questions, that's true. I'm here. But if I wasn't around and you had a question about the Lightning Network the place to go to look up answers would not be, oops, oh no, don't go there. The I would not go to the whitepaper. The whitepaper is out of date.

Where you'd want to go is you'd want to go to the lightning dot github. github.Com slash lightning bolts. You'd want to go to the how lightning works is written out in format that technical readers can understand it ,hopefully. Great.

So if you wanted to find out like How these things work, where the transactions are, what goes in the transactions what messages. So this one, the peer protocol is all about what messages the two peers send and receive in order to set up a channel or negotiate a new version of the contract, right?

Because all of this stuff about the contracts that I've been talking about has to happen through like computer to computer communication. So. They kind of write protocols are really like writing scripts like pre canned scripts that two computers can have at any point that they want to in order to achieve a shared goal, and so that all the messages they send and receive to each other are in the in bolt#2.

So here's how the channel gets opened, here's how the channel gets closed, and here's how you would update the contracts while it's operating, what messages you would send, what signatures you need to send, etc. So that's all in here.

Question was about fees. I'm going to go look and see, maybe it's in the transactions. Hopefully this doesn't make me into a liar. Fees, ha, here we go. Here's the whole section on fees. So the third bolt is all about the transactions that you use, like the, the standardized this is basically all about the standardized contracts, right?

Lightning uses a standard set of contracts. You just update them kind of depending on what your what your counterparty and your balance is, but in generally, the form is the same. You can't go outside of what the standard contract is. It's all written in here, how they should be constructed, what they should look like when and how you should pay fees.

So here's how you calculate fees. Let me see if it actually says who pays fees. Fee payment? Nope, doesn't say. Alright, it's going to turn me into a liar, that's fine. Let me just go back here. Okay, now that we've seen that those exist, and that you can go read them how do fees work? The answer is the person who requests the channel open pays the fees.

This is actually something I'm kind of campaigning right now, campaigning to change, campaigning change there's reasons for that which I will explain shortly. Who funds the channel, so if we go look at the protocol currently, let's go look at the open channel protocol currently the way that open channel works right now, Is that?

No, this isn't. Here it is. Okay. The way that OpenChannel works right now. So this is the network graph of, or like the, I don't know what they call these. It's not a swim lane graph. Maybe it is a swim lane. Anyways, I forget what names are hard. This is the Okay. Node A is the one who wants to fund.

So they're initializing the request to open the channel. So they're the one that sends open channel to the other node. Node B is the funder fund D, or so I like to call them the accepter because they send the accept channel message back. In this channel construction between A and B only channel A really has the opportunity to put money into that shared account that they're opening.

So really it only means that A is has the capacity to send funds towards B at the beginning, because they were the only one who had the opportunity to but if you go to portal plus, and you look for the portal plus that I did there is one in here to change how opens work. It's a couple years old at this point.

I think we're, we're really, really close. We may be weeks away for this becoming spec, which is very exciting. Does this have a, is there a way to look at the version of this? That is, Just gonna see if I could find the the updated channel graph thing. Yeah. Lemme go look over here and go to, I'm not that far behind.

So if I go look at the updated version that has my changes to it there's now a v2 establishment because Swim Lane now looks like this. The basically now though, both parties have the opportunity to put money in the opening channel. Wow, this looks really complicated. All right, that's cool.

Yeah. All right. Long story short Basically, currently only one side has the opportunity to, but we're changing it, or if you're in CoreLightning and I think Eclair right now you can open channels where both parties can put funds into the channel and open, which is really nice. Cuts down on the fees that get paid but who funds the channel, it's usually the person that initiates.

Initiates. Let's be open. Okay, great. We can answer those questions. Nifty and, or the spec, but mostly should be the spec.

Lisa Neigut: Okay. What else is there? There's a lot of stuff I'm leaving out of this very simplified explanation of how lightning works. Lightning. Most of what I'm leaving out has to do with most of what I'm leaving out is how do payments get updates? What am I leaving out? What am I, what am I leaving out?

I'm leaving out anything about making payments. We didn't leave out the whole what happens revocation. So what happens if, so if we go back to this point here, I now have two valid contracts, right? I have one where I had five Bitcoin and the bartender had one Bitcoin. Both of us had to sign this, right?

And the bartender's signature. And then there was another transaction that we made and I signed off where I had given all my money to the bartender. Both of these transactions now have valid signatures from both of us on them, right? How do we make it such that any previous contract that I've signed becomes invalidated?

So we call this revocation, so how to invalidate outdated states. States, so old contracts, or old contracts, old contract versions. So basically, how do we ensure that only the most up to date version of the contract is one that is allowed to be put into the blockchain? Without having these like like, without being able to revoke a prior agreement that you've made it makes going to the court kind of useless because there's no way to prove to the court that there's an updated version of the contract.

Fun fact fun fact eltoo, which is now more widely known as LN Symmetry greatly improves this kind of like, is like a really nice way of being able to send the court the most up to date version of the contract, so to speak. What else? Nothing about making payments, which is like, this would be like onion routing, onions routing gossip.

We didn't talk about gossip at all. That's a minor thing. Is that everything. We didn't talk about closing. We didn't talk about like what happens in a, we didn't talk about the unhappy path of payment, et cetera. But I really don't have time, I think, to talk about all that. Okay, I think I've got about, well, I've got a good amount of time left.

Lisa Neigut: But I want to make sure that I cover, like I don't know, anything else anyone wants to know about. Let's see. The, what was I going to say? I can talk about Core Lightning, how that works. Yeah, let's maybe talk about Core Lightning a little bit. Oops, that was a mistake. Okay. So lightning, there are, oof.

In Lightning, there's like this, these specs, right? Oh, that's the wrong. My thing's really old. Let's go all the way back to here. The Lightning network specifications detail how a Lightning node should operate. What kind of information it should send and receive between itself and other nodes.

Okay. And generally speaking, the goal of the specifications is that anyone who reads them should be able to implement a lightning node from scratch by themselves in a dark room. And hopefully after they've finished implementing it they can spin up their node and it should, if they have followed the specs to the letter, work perfectly with any other node on the network especially and even with other implementations that were written by other people.

So in Lightning, there's a couple of different Lightning implementations. The one that I spent the most time working on is a pretty big contributor to for a long time. Is called core lightning. It's mostly written in C. It's kind of design goals were to be a spec first reference implementation written in C.

That does all the things in the lightning specs, including, you know, a lot of new proposals that come out. We try to be, we want to be the lightning spec implementation that implements most of the new spec stuff and that is contributing the most in terms of moving this back forward. So we were one of the first people to do splicing, we're probably not going to be one of the first ones to do Taproot, but we're hoping to be a very fast follow. So we'll hopefully have our Taproot channels out very quickly after a couple other implementations do. We're one of the first, or we're in the currently in the process of doing our next release.

So our These are the releases, but I think if I click into tags flag recently, just this last week pushed out the latest release candidate for our next release. We try to do releases every three months. So we have a proposal that was going out, which will include some new and exciting lightning updates like splicing.

This one will also include something called so new and exciting things in the next core lightning release. We're adding splicing as an experimental feature, so you'll have to turn it on in order to be able to use it. Also, it's like, not really that user friendly right now but should be improved in like the next release a lot.

The other thing is something called RenePay, so this is a new way, this is a new routing algorithm using cost flow. And then cost flow as a way to make payments. So that's exciting. That'll be launching with this release. So hopefully that'll make making payments more reliable, question mark.

There's something else. There might be something else. Yeah, I think those are some of the big ones. We also did something boring, like adding an HTTP REST Endpoint, to core Lightning, because we didn't have one for a long time. I'm sure there's other exciting stuff in here too, but that's kind of what the project has been up to.

Lisa Neigut: I wanted to kind of walk through how the code's architected, because that's sort of an interesting thing to consider. But, I'm feeling a little tired and yeah. Hmm. See, we've got 20 more minutes. Maybe I can spend, I'll spend like maybe five minutes sort of giving an overview just because I think it's really interesting just from like a software engineering perspective of how some architectural design decisions are made about core lightning that makes it pretty powerful and like well done.

So, hmm, what's the easiest way to do this? Let me see if I've got my...

So I'm currently in a core lightning repository. I just built, downloaded and built the latest master. So hopefully there's no terrible bugs in master right now. So 1 cool thing that core lightning has is that you can hopefully this works. We'll find out. Didn't test it. It's fine. Okay. So there's this script called startup reg test, which is in the contrib file which if you source it into your terminal, will give you some commands, which let you automatically spin up nodes just here locally on my laptop.

So I can just say, start LN. Oh no. My Bitcoin, my Bitcoin node right now is like a little bit, hang on really fast. Let me like fix my... I'm just going to leave that. I'm just going to fix it. Okay.

Cool. Okay. So what it does is it goes ahead and spins up a Bitcoin core node that's running on RegTest, which is local to my machine. It also goes ahead and spins up two extra lightning nodes and starts them running in the background. So I can now talk to them using L1 or L2 CLI and I can talk to the new Bitcoin core thing that it spun up by using BT. So here, let me just show you if I just to get info. Oh, no. All right.

Yeah, great. Okay. So now I have this like lightning node running locally on my machine. One thing that's kind of fun to do is actually show my process ID. I don't think it did. I haven't done this in a while. So I might be a little.

Okay, so what I wanted to show you is I have two, so I have two lightning nodes running. You can tell there's one here and there's another one here. So this is just the processes that are currently running on the system the process IDs. So I can pass one of those process IDs to the process tree. It'll show me all the sub processes that this node spun up whenever I started it.

Well, it's kind of interesting. Oh, it truncated the names. That's okay. Yeah. What's kind of cool about this is it kind of gives you an overview of how how LightningD is sort of architected. Core Lightning as an application is a series of single process, like single threaded, single process programs.

Each of them talks to kind of like a master, it's sort of like we have like this microservices architecture, I guess is what I'm saying, but we do it on using Linux processes. This is because our core dev was a long time Linux maintainer and so he really understands how Linux works. So Core Lightning is built as an application to Take advantage of a lot of just kind of the internal architecture of Linux.

And one of those is we just use processes as as our threads like Unix level system processes. Great. Okay. So what we're looking at here is, this is the, the master kind of like, so we have lightning D, which is a daemon. It's again, a single threaded single threaded kind of like master and controller.

It has access to the database. That's how we do database blocking, so to speak, is there's only one process that touches it, and that's LightningD. And then we spin up new processes in the operating system, running a new program for anything that we want to do, basically. Other thing is, you can write something called like CoreLightning or Lightning plugins.

So I wrote the Bookkeeper plugins, one that I wrote. Funder is another one of my plugins. I've contributed a bunch to this Funder plugin. What these plugins do basically, and Pay is a plugin, which is kind of fun. There's a Pay plugin which means anytime you call like Lightning Pay, you're actually talking to this plugin right here, which is another just like program that's running, it's written in C.

And. You talk to it and then it talks to lightning D and then lightning D kind of coordinates whatever needs to happen to the appropriate other applications that are kind of running underneath this tree. There's three sort of everything that starts with lightning underscore is kind of considered a core part of lightning of core lightning.

Let me see if I can do like a fun. No, that's not gonna work. Hang on, make it look really fast for. Here it is. I want to do this one. I want to fund nodes. So what this is going to do is it's going to like execute something in the script, which will or should create a channel between the two nodes.

So now if I do list peer channels, I will have a node. Which is open it used the dual funding protocol that I wrote to open it, which is pretty cool it looks like only one side funded it though, which is just okay so it's up and ready to go, so I can start paying invoices between these two nodes now but what I, what I wanted to show you is if I go back to PSTree there's now a new daemon, as we call them, that's got spun up, it's called the channel daemon.

And you'll get a new channel daemon for every new channel that you open. So basically every new channel in core Lightning becomes a new process at the operating system level, which is kind of cool. Okay. So, all right, so the place that you can go to look for all these daemon code is in Core Lightning and their names end with a D, so ConnectD, ClosingD HSMD, GossipD, LightningD, OnchainD, OpeningD, all of these contain the code particular to that particular daemon, and each of them has the kind of follow the separation of concerns idea.

Each daemon has its own domain or like kind of like job to be done that it's responsible for. So if you wanted to see how CoreLightning does gossip code, you could go look in the GossipD, GossipDaemon and it would tell you it would have all the stuff that we need and that we use to do gossip. And just to kind of like reinforce this idea that these are all their own little daemons, Rusty went in and did this really cute kind of documentation of all the daemons.

If you want to read through them, all of his comments start with this little tilde mark. And so you can walk through the walk through all the daemons and read about how they work. If you go to the end of the file, that's not working. Oh my goodness. That doesn't work either. Okay. Sorry. I promise I know how to use computers.

All right. Not today though. If you go all the way to the bottom of the file there is a main function because this is where as a program it starts up, right? So each of these has its own, each little daemon in, or lightning as a series will have a place where it as a program can be started. And then we have basically a so all these processes then need to talk to each other.

So we kind of have an inter process communication format that we use. And those are all those are all specified in these csv objects, so to speak. So this is where we specify the messages that all the daemons talk to one each other, to each other, etc.

Okay. I've talked a lot Given you kind of like a very broad overview of how lightning works or sort of what are the problems lightning solving and how it's accomplished that. Sort of talk through what the core lightning infrastructure looks like and some of the architecture decisions that we've made as an application.

Cool. I could do like a pay, I don't know, I could like do 01, CLI, invoice, I don't know. Wait, who has money in this space? I think the only person who has money is also on invoice. I don't know. I've heard that. And then I can pay this with, pay the invoice. We made a payment, which is very exciting. So we just like made a payment.

It's cool. And I don't have any fancy UI. Actually, that's no, I don't have any fancy UI. I can't pay it again. Oh, well, it's already been paid. So when you say pay, it just doesn't, like, it pops back that it's been paid. Cool. And it paid it in one payment, in one HTLC, which is awesome. So okay, I'm going to stop talking about Lightning stuff now.

I promised that I would talk about career opportunities and stuff, but maybe we can just, like, if there's any questions, you guys can answer questions. If there's any questions about core Lightning stuff or Lightning stuff. Maybe we can, like, have 10 minutes of question asking.

Kevin Whitmore: Anybody got any questions? I mean, I've got one around scaling. So obviously we talked about Bitcoin scaling and the challenges there. What are the challenges around Lightning scaling?

Lisa Neigut: Oh, yeah, that's a good question. Okay, how do we, how do we scale Lightning? So I think this kind of depends on, this depends on a lot of things, I think, right?

I think it depends on, ah, depends on the design goals, to go back to design goals of, of scaling or like, what does it mean for Lightning to scale? One thing that people like to run numbers around and then say Lightning won't work because in order to open a Lightning channel, you need to get a transaction mined in the main chain.

So if one of the design goals of scaling lightning is that every human on the planet can have their own lightning channel lightning probably won't scale because it will take, I don't know, X number of years before, I think it's someone did the calculations to say it'll take like two years of nothing but but lightning open transactions to open like seven or eight billion channels, so to speak question mark.

So that's the thing. So I think like, okay, so that's, I think, a pretty valid, I think it's a valid point. I think my pushback is always like, I'm not sure that everyone having their own lightning channel is like a design goal of lightning. Yeah. So I think that's one of the challenges is that there is an on chain cost to establishing a channel.

Another thing, I think one of the challenges I think it depends on who you ask, but currently every lightning channel is two of two. I would say that, I don't know, I go back and forth with this. But this kind of also like So this plays into what if we could have lightning channels with three of three or four of four or like kind of 10 or why not like 100 of 100?

Someone broke lightning, Barack broke lightning, or specifically LND, core lightning was unaffected. But the, by publishing a multi sig transaction, it was 999 out of 998, maybe it was like 998 out of 999 signatures, right? Like why not? Why can't we have, why not lightning channels this big? I think this is really, I don't know.

I have my own personal thoughts about this, which I won't go into, but that's kind of one of the directions that research is going in lightning or at least it's like an open research problem, maybe I should say.

Lisa Neigut: Who's setting the design goals? I don't know. Every man for himself. I don't know.

Lightning is a decentralized protocol, right? So, I think to this point, design goals are really coming from a collection of different places. One of the design goals, so like, there's two teams that work at the spec level who I would say their real their real, like, design goal that they've been coding for pretty closely is for mobile wallet users.

There's certain things that mobile wallet users kind of need and different challenges for having and accepting lightning payments on mobile phones that are being kind of reflected and pushed back to the spec level. I think splicing is actually like probably a really good example of that.

ACINQ. They're a team based out of France who were the first ones to roll this out into production, their last release. Now all of their channels are used splicing. That's because it lets them have like one channel per user and it makes your balance as a user both usable on and off chain.

So you can have basically a single balance lightning wallet now, which is really exciting. The other thing that mobile wallet users are kind of one of the problems that is in what I would say is the mobile wallet like camp would be, oh, what's the word for it? Async payments. Right now, because of the way that you need a contract to get signed in order for a payment to be considered completed, you need both parties in a channel online in order for money to be updated in that channel.

It makes sense, right? You can't have a new updated version of the contract without a signature. You need to be online in order to give someone your signature. So everyone who's on the path of a payment right now has to be online and able to make a signature kind of all at the same time for payments to move.

When it works, it works really well. When it doesn't work, it can be kind of frustrating. But for mobile wallets, or for mobile phones, we're kind of designing for mobile phones to be able to have the private keys on the phones. So one thing about that that becomes challenging then is in order for the funds in that channel to move, you need to be able to contact a mobile phone and get a signature from them in like a timely manner.

So there's currently kind of people exploring a bunch of different ways to do payments where someone along the route basically can kind of hold it for you in escrow or maybe partially complete the payment until you get back online etc. So that's I think that's another design goal that's going through.

The project I've been working on mostly was on like, how do we get both parties to put money in a channel? And then it's actually kind of one of the nice side effects of this is you end up getting decentralized coinjoin, basically. Coordination Another problem I've kind of spent a lot of time thinking about is like how to use market signals to deploy capital to where it's needed in the system so that payments are able to get made because there's balances are available to be moved in the direction people need to move them.

Any, I'm trying to think if there's any other design goals that people are working towards. I feel like the Taproot one largely came out of the Taproot design goal largely came out of Lightning Lab's desire to make Taproot assets happen. But I think this will long term be really good for privacy.

Eventually there's a lot of stuff we need to change in the protocol, unfortunately, before Taproot channels become truly private, but we're working on it. And then what was the other one that it did. Taproot also kind of enables, yeah, there's a lot of, like, privacy sort of benefits here but those are going to be a longer time coming than just getting Taproot into Channel Opens.

Cody: Lisa, I've just got a question if that's alright.

Lisa Neigut: Yeah.

Cody: Yeah, so just regarding the user experience for someone who's wanting to use a self custodial Lightning wallet, at the moment you have to open a channel and have some Bitcoin already. Is there a solution or sort of a way forward for being able to make it as easy as a custodial wallets to get started?

Lisa Neigut: Hmm, that's a great question. I think the answer is... It's a very difficult problem. I think there's like, so it's hard because of the like security guarantees, et cetera, around lightning kind of require you to have at least one on chain transaction to establish that relationship, right, for sending and receiving payments.

There've been some work to do something, they call it zero conf. I feel like this is a fancy marketing term for unconfirmed channels. There's definitely been like, You know, there's a balance between user experience, where I think what people really mean is like speed and what do you call it? Like security?

Because layer one moves at like the 10 minutes to an hour kind of timeline. And so establishing a relationship on layer one, such that you can then do things very quickly on layer two. I think there's, I don't think there's ever going to be, I don't, yeah, I think that's a difficult question.

Yeah. And the United States, yeah, bank transfers take hours or days. So I feel like, you know, waiting an hour to open the Lightning Channel isn't the worst thing. But if you're trying to like pay a barista and you have to wait to open a channel, like that's not going to work. So I think you're right in terms of like onboarding.

I feel like the onboarding thing is like the most challenging. I think the onboarding is like a really challenging problem right now, but ideally in like a five to 10 year period, maybe it won't be as a big problem as we think it is, if that makes sense.

Cody: Sorry if I, if I can just rephrase that a little bit.

So obviously you've got likes of Wallet of Satoshi and these custodial solutions. Do you see the design goals of lightning being that every normal person is somehow involved in this channel side of things, or is the reality for it to scale to the world that it will be some aspect of custodial you know, people managing that for, for normal people?

Lisa Neigut: Yeah, I think realistically, we're going to end up with something that ends up looking a little more hybrid. I think lightning is going, I think lightning is like an amazing and great technology whenever you have like big batches of payments and long standing financial relationships between parties, right?

So it's like I and my bartender, for example, for some reason, I don't know why I need to pay my bartender a lot of money or like, you know, like kind of a back and forth, especially. So anytime that you like need to do batch payments or like you have a lot of transactions kind of happening between two people I think Lightning makes a lot of sense.

If everyone was on Lightning, then all of your payments would be back and forth, you know, if you got your paycheck over Lightning and you were also paying out money over Lightning, then yeah, you would probably have like a good batch relationship with like the ecosystem as a whole. Yeah, what am I trying to say?

I think that I don't know that getting everyone having their own channel is going to be necessarily desirable or like achievable. Given the way that the protocol is currently. So either I think we'll need to change the protocol and to do like multi party channels, or we'll need to come up with some other way of doing ways of representing larger numbers of people in a channel.

If that makes sense, I think, yeah, I think we're going to need that if we really want to scale.

Cody: Receiving a paycheck, for example, you want to save more than you spend. And so eventually you are going to run out of liquidity on one side. And so you have to top it up again and it adds a lot of fees. So yeah, sort of the longer term design goals for that sort of stuff.

Lisa Neigut: Yeah, exactly. Yeah. And I think it's like one of those things where, like, over the long term we'll probably get to, like, you know, over the next decade, growing. So Lightning is growing, I think, pretty organically right now which I think has been really good in terms of, like, giving us time to figure out what we need to change the protocol and what our options are to, like, make it possible to bring people on more quickly in, like, larger numbers.

But yeah, I think it's definitely like a, I think it's definitely a scaling problem. Who's going to solve the lightning scaling problem? I don't know.

Kevin Whitmore: Awesome. Well, I'm just conscious of time, but, and also it's getting late for Lisa, but just wanted to say, really, thank you very much. That was, that was awesome.

Yeah. Don't know Jeff, anything on your side in terms of closing out your class. But yeah, just from, from Web3NZ, thank you very much for taking the time. It's been really cool to, to deep dive the technical stuff is it's great to have somebody with that, that level of knowledge and experience and able to explain it as well to noobs like, like myself.

So yeah, just thank you very much.

Jeff: It's fantastic to actually see, see you at it. And I love your perspective of talking us through design goals. That's perfect.

Lisa Neigut: Cool. Great. Yeah. I feel like I should plug my Udemy class. So if you guys want to see a little more of the technicals of how Bitcoin works I'm going to just drop the Udemy link to, hopefully that works.

This is the, I started doing like an online class that teaches about Bitcoin Bitcoin basics, so like what goes in a transaction, what are the different scripts, how does script work I'm currently working on the second half of the class, which is all about cryptography, so it goes through what is ECDSA, how do signatures work. You actually implement the math on how ECDSA is, and then we do you know, learn how signatures, how to like build signatures for Bitcoin transactions and do multi sig, so I'm hoping to do that class out before the end of the month but yeah, you should check out the Udemy stuff, and then if you're ever anywhere where we are doing live in person classes we're going to do our first taproot class, In Atlanta ahead of the Atlanta Bitcoin conference at the beginning of September.

And then I'm going to be teaching more lightning classes. This is kind of like a preview of the lightning class that you guys have maybe gotten half of day one now but I'll be doing live in person lightning classes in Austin and in Switzerland. So nothing in Australia, unfortunately, but if you're out in any of those places maybe for the Plan B Lugano conference, I will be doing a lightning class ahead of that in October.

Kevin Whitmore: Awesome. Lots of travel. Nice one. Awesome. Well, thank you again. If we've got any questions, we'll, we might reach out, but I'll also put the Udemy course in our, in our, in our community as well. And yeah, thank you very much.

Cody: Thank you, Lisa.

Lisa Neigut: Thanks all, see ya.

Kevin Whitmore: Cool. Thank you.