{ "episodeId": "SLP378", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "christian_decker": { "name": "Christian Decker", "role": "guest", "tag": "CHRISTIAN" } }, "segments": [ { "speaker": "stephan", "time": "00:06", "start": 6.14, "text": "Hi and welcome to Stephan Livera podcast, a show about Bitcoin and Austrian economics. Today my guest is Christian Decker from Blockstream. So Christian rejoins me on the show and we talk about Greenlight, which is an easy way to have a hosted lightning node set up for you by the Blockstream team. We talk about some of the trade-offs around this, who is it for, as well as talking about lightning network generally. Where it's at today, the latest stuff coming with core lightning, as well as some discussion about any prevout. This show is brought to you by Swan Bitcoin, and if you wanna help educate yourself or your friends and family about Bitcoin, there is the Swan Bitcoin cannon. So swanbitcoin dot com slash c a n o n. This is basically a list of curated rabbit holes by various people in the space. Lin Holden has one, Matt O'Dell, Jameson Lopp, Guy Swan, I've got one as well. Basically, these are different rabbit- Polls with curated lists of resources that you can use to learn about Bitcoin. The mission at Swan is to create ten million new Bitcoiners. This isn't just people who are stacking sats, but people who truly understand the importance of Bitcoin. Education is key to accomplishing this mission, and we hope the cannon will be a collaborative effort to help make it easier to share Bitcoin education with the world. That's swan dot com slash cannon. Voltage is paving the way as the leading enterprise-grade lightning solution for anyone building on layer two. Lightning is the future for Bitcoin payments and can no longer be overlooked. Voltage helps to integrate lightning and payment infrastructure into your solution quickly and in a hassle-free manner. Don't waste time with maintenance and integration, deployment, and iterating. Whether you want to route payments, build your small business, or scale an enterprise company, Voltage is the solution. Don't stumble on your own infrastructure. Go get started at voltage dot cl. Loud. If you are looking to upgrade your Bitcoin hardware security, CoinKite dot com are the creators of my favorite Bitcoin signing device, the Coldcard, and they have the Coldcard MK4, which is available for pre-reservation and has been shipped out to some individuals. I've had some, and I've been playing around. I find it really slick and smooth to use. It is faster, and it has all kinds of new features. It's got more memory, it has two secure elements, and you can use it with NFC. So there's all kinds of features And things you can play around with as part of the cold card. I think the most popular feature is being able to use it in an air-gapped way, so you can use a micro SD card and move that xPub file out of your cold card into your computer and use that to move transactions back and forward. So go and buy yours at coinkite dot com. Christian, welcome back!" }, { "speaker": "christian_decker", "time": "02:45", "start": 165.23, "text": "Hey, Stefan. Thank you very much for having me back." }, { "speaker": "stephan", "time": "02:49", "start": 168.67, "text": "Yeah, so it's a crazy world out there, right, as we speak right now. It seems like the, UST thing is, breaking down as we speak, but nevertheless, development continues and the Lightning Network is growing, and I'm excited to see that. I, I definitely see a lot of cool things happening in the Lightning world, and, yeah, wanted to chat to you today about what you're working on with Core Lightning now, not C Lightning anymore, and, of course, Greenlight And, yeah, just kind of what's happening in the space. So, yeah, let's start a little bit with the green light stuff because, as I understand, like from my reading, it seems the idea is, hey, look, it's difficult for people to fully do their own thing. The idea is Blockstream is going to do this as a service to help people make it easier, and not have to be as deeply technical into the Linux and the management of the node and things like this. Could you give us your summary, like, what is the reason" }, { "speaker": "christian_decker", "time": "03:45", "start": 225.49, "text": "Absolutely, yeah. So until now, it, it basically has always been the choice when you wanted to join the Lightning Network, you had the choice of either going for a simple custodial wallet that would do everything for you, you didn't have to learn anything, but there's the evil C word in there, right? Custodial. And then on the other side, you had to basically dig through hundreds of tutorials, learn about Linux, learn about how, how Bitcoin works, and on top of that, have to learn Talking about, about Lightning and, we as a community certainly didn't help by basically shaming people into, \"Oh, you have to learn this and this and this and learn multisig before you ever touch Bitcoin, because otherwise you're at risk of losing, losing your funds.\" And so that had the effect that we got, we got many new community members that were really, really well-informed. But I al-well always think about the community members that we lost along the way, right? Where we- that didn't have the time, didn't have the incentive to, to read through all of this, this huge pile. And so we thought about how can we improve this, and, and Greenlight is basically what, what the end result is of that. we wanted to pull sort of the, positive experience of seeing what Lightning could do for you before you had to invest the, the time to actually learn about this stuff, become, become a self-sovereign participant in the network, and basically give you a glimpse of what the payout- What will, will be once you do that. And so what Greenlight is, is basically we looked at a, at a lightning node and thought about how could we split it up. Core Lightning has always been a very modular, system that has had parts that you could swap out and customize for your own needs so that it very easily was a-- we were able to pull apart and, and sort of distribute parts in different, different locations. And what we ended up with is Greenlight, a hosted non-custodial- Service and, we think that it is sort of a new point on the spectrum by basically us running, the infrastructure, basically provisioning all of the stuff that you have to do for to run a lightning node, including watchtowers, including st-uh, databases, including backups, including authentication, including the Bitcoin backends and, and so on and so forth, and, you as a user have basically a remote control for that node. And you always have, you are the only one that has access to the signing keys, which are needed to, sign off on any changes that touch your funds, because these really are your funds. We aren't managing them for you. You are in full control of, of what happens with these funds." }, { "speaker": "stephan", "time": "06:33", "start": 392.92, "text": "Gotcha. And so in terms of target user for Greenlight, I'm thinking out loud here that it would be, let's say, a business who wants to get started with Lightning, but they don't have- Somebody who's like a deep in the weeds Bitcoin and Lightning enthusiast who's gonna spend all day every day trying to figure this out, and potentially for an interested person who just wants to play around. Is that essentially what your target user is here?" }, { "speaker": "christian_decker", "time": "07:00", "start": 420.04, "text": "Exactly. So we do have two target audiences, in the end. We certainly have the, inexperienced but, but enthusiastic, end user in mind that wants to sort of, they would just want to download a wallet on their phone Phone, get started paying and, and receiving, Lightning payments, and that includes, small business owners that sort of are at the beginning of their journey. And, on the other hand, we also want to provide a platform for app developers that might be really, really good at what they do best, namely user experience, user interfaces, and, and just building those innovative, applications, but they might not have the expertise for, for Lightning. So We sort of serve these two, audiences by basically providing a, an application programming interface to, application developers and by providing, node setup in a matter of seconds, to, to end users. So the user experience should, should really be that, you go to the app store, you download an app, you get shown twenty four words, and you're done, basically in the time it took you to, to, to open the app. In the meantime, we've- You spin up your personal Lightning node, which is a open source core Lightning node as, as you would find it if you installed it yourself, and, you can then basically just interact with it and start performing payments, receiving payments, and, and doing anything you want, be that podcasting or be that participating in online auctions or tipping people on Twitter." }, { "speaker": "stephan", "time": "08:39", "start": 518.8, "text": "I see. And so for that user, I guess they've got a few different choices in their mind currently, right? They might just use Let's say they go and buy a Raspiblitz as an example, and then they do Core Lightning on that. And how would you distinguish that kind of idea of like buying this kind of node in a box and setting it up in your business versus doing a Greenlight setup?" }, { "speaker": "christian_decker", "time": "08:59", "start": 539.14, "text": "So we, we definitely encourage anybody to go for the Raspiblitz, version. Greenlight isn't intended as the final destination for, for users. It's a way for, for users to onboard, get some education, learn about how this stuff works. And then Eventually we, we'd like to people to actually off-board into their own infrastructure, because that is ultimately the most secure way of, of operating on Lightning. there are some trade-offs in, in, in Greenlight, we do have some visibility that we don't really want, and so eventually we'd, we'd like, people to off-board and take on their own responsibilities. And therefore, that also informs our target audience being enthusiastic new users that might not have- Have all of the experiences to actually run a Raspberry Pi with Lightning or set up anything else, we are trying to sort of grab market share from the custodians, which we don't think are a, a good option at all, and, and sort of get them more on the path towards, self-sovereignty." }, { "speaker": "stephan", "time": "10:04", "start": 604.0, "text": "I see. And so then, is the idea that somebody might-- and maybe this is going to happen as well, is that there may be wallet providers out there who are actually gonna use Greenlight in the background? To sort of quickly spin up a node for their users, and I guess that's partly-- that, that's maybe from a Greenlight point of view, that's sort of partnering on the business side, but in the background, actually it's Greenlight sort of helping them spin up the nodes that are required for those end users who, who just want the, you know, wallet on their phone." }, { "speaker": "christian_decker", "time": "10:33", "start": 632.96, "text": "Absolutely. That, that is, that is something that, that we are already doing. We announced during Miami, for example, that Breeze is going to migrate over to, to Greenlight, and we have a couple of, other integration partners that we are currently partnering in a, in a closed beta form, and sort of trying to build out a bit of an ecosystem of applications. The most interesting part here is why is it interesting for application developers is because we don't actually include the- node with, with the application itself, it means that a user can share a single node among many different applications, and that has a number of advantages for users, but also for app developers. For users, for example, they don't have to split up their funds, right? You don't have to have fifty bucks on a podcasting two point o app and fifty bucks on your Lightning wallet, and then as soon as you want to pay fifty one, you're out of luck. you can actually pool off all of your funds, you can amortize the management effort that you would put into a single node and not s- multiply that by the number of apps. But also for app developers, it's really, really interesting because the, the mode to- Switch from one app to the other and just sort of try it out for, for a couple of minutes doesn't mean that you sort of have to tear down a whole different app, move funds over, and then reopen channels, and all of a sudden the day has finished, right? And you still haven't seen what, what the app can do. And so this is, this is general to these remote, node, setup, but I think that, that light, that green light can help us sort of popularize this and eventually get, get more people into deployment of Lightning for each user." }, { "speaker": "stephan", "time": "12:17", "start": 737.47, "text": "I see. And for some users, it might make sense as well if they wanna use it more like a remote node, I suppose. and also there are various aspects that are being done professionally by, you know, a team who manages it, this as their job. So I guess it's similar to like cloud computing, right? Like people using a cloud service, well, it's sort of like a cloud node. I guess the other question people would have is, so at least with my understanding of Lightning, when you do, like, let's say You know, I'm either routing a forward, a payment through to you, or I'm directly the one making the payment to you. So in practice, my node and your node have to both sign the new state of transactions before we can have that transaction completed on the Lightning Network. So how does it work then when the user is still holding their own keys but the node is in the cloud? Like, how does the node, how is the node able to sign an update to the channel?" }, { "speaker": "christian_decker", "time": "13:09", "start": 789.03, "text": "Exactly. So the point here is that basically whenever we have, we have- We have anything that requires a sign-off from the keys, be that an on-chain transaction, a connection open, there, there is a cryptographic handshake involved there, or a change in the channel state, we need, we do need to have a signature from the keys. So what we do is we basically take this message that, that contains all of the information for this request, and we send that over to the signer, the signer independently verifies that everything is okay and only then signs it and sends it back. Now, as you correctly pointed- Point out if the signer isn't there, there's not a whole lot we can do. And that is also why we, why initially we concentrate on the end user experience where routing isn't something that, that, that happens, very often. And I do believe that sort of, newbies that, that just want to learn about, stuff are most likely to be leaves in this, in this network of, of, of node graph. So it definitely isn't meant for, for huge Routing nodes because I think they would have the chops to actually run, run it on their own infrastructure. So that's, that's yet another incentive to sort of, once, once you want to dip your toes into routing territory, you might, you might be better, suited for, for a self-hosted version." }, { "speaker": "stephan", "time": "14:32", "start": 871.6, "text": "I see. So yeah, so it's seen more like it's training wheels, you know? Like the idea is you, you're on this for a little while and then eventually you're ready to move out on your own like an adult and, take The user, the training wheels, things like, authentication you mentioned as well, I'd be curious, how does this work from the user's point of view? As I understand, let's say in like a Lightning Labs LND paradigm, they've got the macaroon, and so the, the idea is you might tran-- you might have the macaroon that is the admin macaroon that allows you to then remote control that node. So how does it work in a core lightning and a greenlight context in this way?" }, { "speaker": "christian_decker", "time": "15:08", "start": 907.81, "text": "Absolutely, yeah. So, so what we do is, The RPC, using gRPC, which is also what, what, LND uses by the way. And underneath that, we use an encrypted transport called, called mTLS. So, that means, that stands for mutual transport layer security. And the idea here is that, both the, both the client as well as the node have a certificate, and the certificate, is unique for each of these devices, and only if the correct, client connects to the right node We will, we will, actually enable access. On top of that, we may eventually layer on macroins to sort of, once you have access, restrict, individual users, but that is currently, not yet built out, but certainly possible. Currently, if you have access to the, to the RPC, you have, you have full access. That's one dimension of authentication. The other dimension of authentication is, well, what tells the signer that, the operation that it is about to sign Sign off actually comes from a user and not an operator or an attacker that might have taken over the, the host running the node, right? And so for that, we have, we have built what we call end-to-end security where the, where the client, whenever he, they issue any, any command, they will sign off on that command and the command will be passed along to the signer and as, as context, and the signer will then take apart this context CO, so- So there is a balance change of X in channel Y, which command does this correspond to? And only if, if it has a, if it has a matching command from a correspond, from an authorized, client, will it sign off on, on changes. so it is very important for us to make sure that, that we never ever, have control over funds, and even if our hosts were compromised, then, then, well, it wouldn't be, affect your funds in any way." }, { "speaker": "stephan", "time": "17:14", "start": 1033.81, "text": "Excellent. And so as an example, in the future then, let's say you want to be a merchant and you might wanna have different permissions for the employees in the store, in the store as opposed to you, the merchant, who's running the node. So maybe that's an example where it might have abilities for you to give permissions that say, okay, only refunds up to this amount, not like being able to send, you know, just treating everything like it's a hot wallet and they can just spend back all this money, and obviously then there's all this possibility for like embezzle- And so on and so on. Exactly. So that's, that's one example. Like," }, { "speaker": "christian_decker", "time": "17:46", "start": 1065.69, "text": "like if you, if you have a point of sale that might only be able to create invoices whereas an, a back office might be able to perform, pay payroll as well as create invoices, and then you might have an accountant that only ha-has read-only access and, and so on and so forth. It's also quite interesting that the signer is basically the perfect place to, to have an audit trail. because it sees every single movement of, of funds, it has all of the initiators, namely who, who in, who sent that, RPC command and so on and so forth. So it, it might just be interesting from that point of view to really have a step-by-step, account of what happened to your funds and be able to say, \"Oh, this was initiated by cashier, A and, and then later settled after ten minutes or so.\"" }, { "speaker": "stephan", "time": "18:37", "start": 1117.46, "text": "Yeah. And so when we're speaking about the signer here, what device is that running on? Like, is that on a phone? Is that on a PC somewhere? Like an always connected PC? Like, what are your thinking, what are your thoughts there on the signer for the typical customer here?" }, { "speaker": "christian_decker", "time": "18:51", "start": 1131.1, "text": "Yeah, so the signer is basically just a piece of software at the moment. It is a library that we bundle with the client itself. So wherever you have your app running, it, it basically is included in the app itself, and it will automatically connect whenever you have the app open. That being said, we can have any number of, of signers for individual nodes. So you might have your, your app on the phone, you might have a Raspberry Pi at home, that sort of the first step towards taking on more ownership that is online twenty-four hours. And so whenever, whenever your, your app starts the node or we start the node because there's an incoming payment, you could have the Raspberry Pi auto-connect to your node. it also suits very nicely for for Uncle Jim setups or Uncle Bob setups, I can never remember which one it is. Uncle Jim, yeah. Where, where basically you have one, one, tech enthusiast that, that sort of digs all of this stuff and will, we can set up signers for their family and closest friends. So that is, that is how it looks at the moment, but we are collaborating with the verifying sign, lightning signer team, Deif Randam and Ken Cedric on basically building Building out the protocol for a, for a verifying lightning signer, this is open source, the work is, is actually awesome. and, I think the goal, in the end there is to make, to make it such that we have a signer protocol that we can attach to any, lightning im-implementation, not just core lightning, and act as a, as a remote signer that can then basically take care of your funds. And whether that's hardware, or- Or software or on each app, it really doesn't, doesn't make a, make a lot of difference." }, { "speaker": "stephan", "time": "20:44", "start": 1243.95, "text": "Yeah. And I'm curious as well, like in terms of the approach with- So let's say if somebody's doing this and they are, presumably, like using a phone app to connect back, right? Like using Spark or something similar to connect back to their Greenlight node. What happens if they go offline at the time? Is it just kind of like the node can still kind of accept a payment 'cause it might have already generated the invoice? And if you're offline, it's no big deal, like, like we were saying, because you're more likely to be a leaf node as opposed to like a really deeply well-connected node very close to the center of the lightning channel graph" }, { "speaker": "christian_decker", "time": "21:18", "start": 1278.29, "text": "Yeah, the main issue with, with, users going offline is basically that we can't sign off any changes on, on funds, and that sadly includes, receiving, receiving invoices. So there's a bit of a trade-off, we trade, we traded off more security for a bit less availability, but we're, we're hoping to, to compensate, for that by basically enabling users to have multiple signers, to have multiple apps, and reach out to, to signers that- that might not be online at the moment, so there is a bit of a notification system in the background where, where we plan to, hey, there is, there's some action going on, there is a signature required from, from a signer, let's try to reach out to anybody who isn't online at the moment and, and see if, if they could potentially sign off on it. Gotcha. The note itself, if the signer isn't, isn't present, isn't much use, because we can't actually do much. So what we do is after a, a period of in-inactivity, we will shut down that node. That is basically how we can, besides the high-density deployments we can do for Core Lightning, we can save additional resources, and these, savings, are, are then passed on to, to, to users, once we figure out how to monetize this." }, { "speaker": "stephan", "time": "22:37", "start": 1357.14, "text": "Gotcha. And so, just to give people a rough idea, like what kind of cost are they looking at if they wanna sign up and have a greenlight node?" }, { "speaker": "christian_decker", "time": "22:46", "start": 1366.18, "text": "So the, the cost on our end, are really, really low. I'm, I'm speaking, sub two dollars per month per user. Oh, okay. And, and so we don't, we don't really know how we are, we are going to basically- Pay for it, as of right now. there are a couple of, of things we, we are looking into, and hopefully we can hide that as much as possible from users such that it really becomes a no-brainer to, to operate, right? We'd like to, for example, instead of, instead of charging explicitly for, for the, the nodes, we'd like to charge for, payments being sent and received, through the, through the built-in fee mechanism in- Lightning, and that has the nice side effect that it is basically pay per use. so you're not using your node, perfect, we, you don't, you don't get charged. If, if you're a very active user, then part of, of that, of your payments is going towards the node itself, and that is basically built into the Lightning protocol itself. We also have a number of, of partnerships with LSPs, whom we are basically providing providing users. and so there, there, there are ways we can basically agree on, with them, how, if, if they want to share some of the revenue with us. Yeah. So that's pretty much still in flux. Can't promise we will manage to make it transparent, but, we're definitely trying to." }, { "speaker": "stephan", "time": "24:22", "start": 1461.92, "text": "Yeah, interesting. And so, in terms of things like managing your watchtower as well, so you mentioned this idea. So currently, it's probably not that easy to run a watchtower unless you're already Already are a technical user, so this might be another aspect of it. So what's the, watchtower setup going to look like here?" }, { "speaker": "christian_decker", "time": "24:41", "start": 1480.6, "text": "So what, what we do is basically we provide a watchtower by default. You, one, if you spin up your node, you are automatically registered with the watchtower. we're not charging extra for that, so, it, it basically is just a free added service. But once you, once you have, started digging into Lightning, it might be interesting for you to switch Sort of start using, become more, involved in some of these processes. And the watchtower is just one of these examples, right? You can, for example, have us run one watchtower for you, but you could start by basically taking the watchtower and deploying it on your infrastructure and have it an additional safety net, right? Y-your watchtower could, could watch the, the channels for you as well as we watch, watch for, for the channels. And so this is, this is part of our offboarding strategy where we have a number of different, different services, including the watchtower, including the database backups, including the routing information for, for the network that you can selectively sort of start streaming onto your platform and sort of see how things work, before making the big move of the actual node move, and move that over to, to your infrastructure. That being said, the inverse is also true. We have a couple of services that we will also offer to, to users that have off boarded. so for example, we are currently working on a reverse proxy that gives each node a unique, URL, and that will then be fixed across all time, so if you have your, your wallet configured to connect to a certain, lightning node that is at the moment hosted by us, and then you decide to migrate it off on- onto your own infrastructure, that URL will co- will continue to be reachable from outside, and we will forward, those connections to your node instead of our, our hosted node. I see." }, { "speaker": "stephan", "time": "26:43", "start": 1603.49, "text": "Yeah." }, { "speaker": "christian_decker", "time": "26:44", "start": 1604.31, "text": "And so you don't have to reconfigure your, applications, and all we do is we basically look at the encrypted, stream. there, there is a server name indication extension to the TLS protocol, which allows us to say, \"Oh, you want to talk to x y z dot greenlight?\" Greenlight dot blockstream dot com. Okay, here we'll hand that forward and all we see is, is basically encrypted traffic, we don't see the contents and so on and so forth. and it basically allows you not to have to reconfigure all of your applications, just because you, you have, you migrated off of the, platform. And that is similar for backups and, and watchtowers and so on and so forth. we plan to offer them as well." }, { "speaker": "stephan", "time": "27:31", "start": 1651.32, "text": "so yeah, right. So the idea is they can sort of gracefully offboard. And then, so on a backups point of view, as you bring that up, what does that look like? So I mean, there's, I guess there's different concepts to understand User will have their seed backup, right? That's their twenty-four words, but then separately, there's database backup. And, you know, like what's contained as part of this backup?" }, { "speaker": "christian_decker", "time": "27:52", "start": 1671.85, "text": "So the backup we, we talk about is, is actually just a, database backup. So we run a, a replicated cluster of Postgres, databases on, in the cloud, and we do, we basically use those to back all of the nodes of all of the users. Replication is a first- Of defense, right? If one server goes down, we do have other server, servers to fall back on. And we take, we take incremental snapshots of, of each change in the database itself so that we can, we can recover should everything basically be flooded. And then we can take those, those incremental backups and can, we can stream them to the client. So in that sense, even, even if from, from today to tomorrow we were to disappear completely, you could take the- This backup, rehydrated and imported into your, your database, and you'd basically have a functioning node again." }, { "speaker": "stephan", "time": "28:51", "start": 1731.09, "text": "And so the other thing people are having to learn if they wanna be a self-sovereign Lightning user is channel management. So who do I open channels with? How do I rebalance them when they go out of whack? Do I need to use on-chain and off-chain swapping, like if, let's say, I've got all the SATs on my side of the channel and I need to sweep it out, how does that work? Greenlight context." }, { "speaker": "christian_decker", "time": "29:14", "start": 1754.17, "text": "So that is definitely part of, of the promise here that, that we want to assist as much as possible with, with this kind of management, and we want to make it as, as easy for users to, to start as, as possible. And for this, we have, we have a number of agreements with, liquidity providers that participate in a system with us that is still being built, so not, not everything is set in stone at the moment, but the idea is basically that if- If a wallet notices that, oh, I'm creating an invoice, but I don't have any incoming liquidity, I need an incoming channel, then we can, we can reach out to these LSPs, sort of figure out what the best, what the best capacity for them is, and then send back those proposals to the app themself. And then the app can say something like, \"Oh, you don't have, you're not well connected enough. Would you like us to, to do that for you?\" And if the user clicks yes, we can basically pick one of these One of these proposed channels, we can stage it with the liquidity provider, and once the payment comes in, only then we will, yeah, go through the motions of actually opening the channel, transferring the payment, and, sending back the payment for the liquidity provider. So it should be really low touch, but like I said, it's, probably the, the difficulties are usually in the details here." }, { "speaker": "stephan", "time": "30:38", "start": 1837.58, "text": "Of course. Right. And it, it does remind me a little bit of this, like Phoenix on the fly channel creation, but, but maybe arguably in a more decentralized-ish kind of way, or at least with multiple possible liquidity providers, whereas in the context of, let's say, a user who's receiving on Phoenix, your channel is coming from Asynq and only Asynq. So I guess that's one difference" }, { "speaker": "christian_decker", "time": "30:57", "start": 1857.25, "text": "there. Exactly. Yeah Into how we could use dual funding, which Core Lightning pioneered and liquidity adds of course, which are pretty much, the first half of the, of the, of the whole construction, right? We, we know who is willing to open what channels for what price. And now we just need to make sure that we can actually open it with the zero confirmations, that, that they, LSP knows how to wake us up if the node is, currently offline and, and all of these smaller details. But we're, we're looking very much for a, protocol, level solution first." }, { "speaker": "stephan", "time": "31:39", "start": 1899.3, "text": "Yeah, that's really interesting to see. And so with, well, dual funded channels or collaborative channel openings, that's, really cool as well, because then we're, we're having a scenario where both partners of that channel are putting up some money into that channel, and so it just becomes like, well, I guess the main, one benefit is obviously the channel starts out with, with the possibility to send either way. It's not just like, I open the channel to you, and I can only spend to you, I can actually receive from you as well." }, { "speaker": "christian_decker", "time": "32:07", "start": 1927.1, "text": "Yeah." }, { "speaker": "stephan", "time": "32:07", "start": 1927.44, "text": "And the other Maybe a little bit of a privacy benefit in that on chain, it's not as clear who's put what into where, and so that might also help from a, a little bit from a privacy point of view." }, { "speaker": "christian_decker", "time": "32:18", "start": 1938.49, "text": "Exactly. Not, not just that, but also you have a very much reduced on, on chain footprint, which means you are saving on fees, you have less data to track, you don't, you don't have that much of a footprint overall, and so it, it definitely makes it harder for, for an outside observer to see, oh Who added which funds to this channel? So it, it is basically a coin join, to create a, a channel." }, { "speaker": "stephan", "time": "32:46", "start": 1966.21, "text": "Yeah. So maybe it's like a, like a pay join, right? Like we both contribute into, that. And so from a liquidity add point of view, is that something being managed at the Greenlight node level or is like the user being able to- Do that themselves? How does that part work?" }, { "speaker": "christian_decker", "time": "33:03", "start": 1982.52, "text": "So generally speaking, we do, we do expose the entire RPC interface from, from, Core Lightning. So, if you have something that currently uses the Core Lightning API, you can, you can just adapt it to use the Greenlight node API, and that includes stuff like, like adding, adding liquidity ads or listing liquidity ads and, then opening channels. We definitely do encourage users to get familiar with the, with the API itself, and so we also don't put any limits as to whom, whom you are allowed to open channels to. So you could basically just, just do it manually. It, it is after all just a core Lightning node in the cloud." }, { "speaker": "stephan", "time": "33:46", "start": 2026.09, "text": "I see. Yeah, so I mean, you could just, yeah, I mean, at the end of the day, like you could SSH in and just literally do it all command line if you wanted to, but the idea is this is like making it easy for people who maybe aren't at that" }, { "speaker": "stephan", "time": "34:00", "start": 2039.88, "text": "And so turning to, I guess, core Lightning as well, I see, you know, the new version, version zero point eleven, has, the one I saw is, you've now got the ability to have multiple live channels to the same peer. Now this is kind of an interesting difference in some of the implementations, because before it was like, oh, people could do multiple ones with other implementations, but with c-lightning back then, it was seen like, no, just one channel. And now, I guess, it's kind of seen like, well, Is that basically what happened?" }, { "speaker": "christian_decker", "time": "34:31", "start": 2071.26, "text": "Exactly, yeah. We, for the longest time, we had a bit of an ideological, stance against, having multiple channels with a single peer, because if you, if you open two channels to the same peer, then you're not increasing your, your resilience against, single points of failure, whereas if you, if you were to use that second channel to open to somebody else, you could basically increase your resilience, and reduce your, your risk of, Basically that one golden, peer going down and you being cut off from the network. And, it has been, it has been a feature that has been, long requested. we still maintain that it is probably better to have a diverse set of, of peers and then do indirect routing to actually reach your destination instead of basically just opening a channel directly to Starbucks and then doubling down on that every time that your, that, that your channel is exhausted. But yeah, it, it has been requested and, there are some scenarios, especially for large, nodes that, that sort of have built this backbone in the network, for, with huge channels. For, for them, i-, it was really important to have this, ability to increase capacity on a whim, and, we always wanted that to be splicing, where you could basically add or remove funds from an existing channel without any downtime On time, but it, it just took a bit longer to, to build out splicing. we now have one engineer working on it and he's making a lot of progress, and I'm really looking forward to after six years of talking about splicing, actually seeing it in action. But, yeah, the basically multiplexing channels has, has been a feature that, that we just needed to support after all. And Rusty has done a, an amazing job at refactoring all of this stuff and making it possible, in the last- In, in the last release, so kudos to him." }, { "speaker": "stephan", "time": "36:33", "start": 2192.62, "text": "Back to the show in a moment. Brains are the creators of Brains OS Plus. This is firmware that you should be thinking about installing on your ASIC mining machine. You can improve your efficiency by as much as twenty-five percent. You can point your hash rate towards any pool, or if you use this and then also point your hash rate towards Slush Pool, you get zero percent pool fees. Now, it's on the website at brains dot com. You can go there and check which models are supported out of the S nine 19 range, S-17 range, and in the development pipeline, there's Wattminer M20S and some other Antminer X19 models coming soon. So this is a great way to get more hash rate for your electricity spend and improve your efficiency. So that website is brains dot com, that's b r a i i n s dot com. Unchained Capital are making it easy to upgrade your security to multi-signature. With Unchained Capital, you can hold two keys and they will hold the third key, and in- In doing so, you are removing single points of failure from your security setup. So if you need assistance with this, there is a concierge onboarding program where you sign up, you pay upfront, they will send you the hardware wallets and do a call with you to teach you how to do this. Remember, even if you've never held your own private keys before, you can use this program and they will teach you how to do it, set up the vault, and deposit a thousand dollars of Bitcoin in your vault. And with Unchained, you can also make use of their education and other services available All of this over on the website at unchained dot com slash concierge. Use code levera for a discount. Lend at hodl hodl is a peer to peer Bitcoin backed lending platform where you can anonymously borrow stablecoins against your Bitcoin. With lend at hodl hodl, you no longer need to sell your Bitcoin to get some liquidity. You can borrow stablecoins by putting up some Bitcoin into an over collateralized loan. With lend at hodl hodl, all deals happen directly between users, so you can go there, you can either take an offer that's already there, or you can Depending on how long you want to borrow and the interest rate that you are looking to pay. So go and check that out. The website is lend dot h o d l h o d l dot com. Back to the show with Christian. Yeah, and I'm, and I'm excited to see splicing as well, because I think that would make it a lot more practical to-- so, I mean, right now people are using, let's say, swapping in and out to sort of manage the current size of that channel, but if you actually wanted to make it bigger or make it smaller, that's where a splice could really be a cool feature to have, because then you're not having to close it down, reopen the channel, it's just one on-chain transaction to, I guess, resize that channel. So I, I guess, we can talk about that idea, but actually in practice, achieving that is maybe not as easy to do as what we're talking about." }, { "speaker": "christian_decker", "time": "39:16", "start": 2356.37, "text": "There, there are a lot of details in that, but I mean, even more exciting than, than adjusting the size of a channel, which, okay, you might do every once in a while, is the fact that all of a sudden you can, you can perform on-chain payments out of, of a channel. Gotcha. which gives you this, this ability to basically have an app that is pure Lightning, One balance, hey, this is how much you, you, you currently own, and then you scan, an on-chain Bitcoin address and, and send, send a payment to it. And what happens in the background is basically it takes all of the funds that, that you had, in a channel, it quickly closes it, splices out some funds to that address, and then reopens it without any downtime. Yeah. And so that, that is a huge mental barrier at the moment that, that people have to overcome. Oh, I have an on-chain have an off-chain balance, and then what do you do if, if the off-chain balance isn't sufficient anymore? Do you open a channel now? Oh, you have to wait an hour for that to happen? And so I think just from a usability point of view, splicing is an amazing feature." }, { "speaker": "stephan", "time": "40:27", "start": 2426.56, "text": "Yeah, that's clever. Yeah. And I think it's like, there's different approaches in the ecosystem right now, right? Like with Phoenix as an example, if you use that, it's really, you're paying out to an on-chain address. It's like using a swap provider in the background. Or with Moon, it's sort of, kind of like a splice, but kind of, it's slightly different. And so, yeah, it would be really cool to see like genuine splicing coming into And it's" }, { "speaker": "christian_decker", "time": "40:51", "start": 2451.42, "text": "less trust, trusted than, than a swap, because if you want to, if you do a swap onto, onto an on-chain address that doesn't have the ability of actually transporting an HTLC, then what you're basically doing is giving the swap provider, hey, here's, here's a payment, and the swap provider says, okay, I promise I'll turn around and send that on-chain, because we don't have, we don't have a tool to send to a generic address in a secure, In a secure way that, is atomic, right? Yeah, right. That is, that is the main issue there. Yeah, yeah," }, { "speaker": "stephan", "time": "41:27", "start": 2487.28, "text": "that makes a lot of sense. It depends, obviously, so many things, there's so many moving parts and variables here, but it could end up being cheaper too, right? Because if you're just splicing out, you might not have to pay a service provider who's giving you this swap in and out functionality. Now, of course, we may still need swap providers in the Lightning Network, just as we need LSPs, Lightning Service Providers in" }, { "speaker": "christian_decker", "time": "41:51", "start": 2511.46, "text": "Well, the, the swap provider does also have an advantage in that he can, aggregate a lot of swaps into a, into a single address. So it probably depends on how much traffic there is on the swap and how long you're willing to wait for this aggregation to happen. because if there is a payment that comes in every hour and the swap provider waits for ten of them to accumulate, you're probably waiting for ten. So there, there's probably a balance there." }, { "speaker": "stephan", "time": "42:18", "start": 2537.5, "text": "Right. So, so if they can do like a batch transaction, it's kind of the similar dynamic of, you know, exchanges instead of just doing exchange withdrawal one to one each time, they can do like one batch transaction out to like ten people or fifty people at once. So big saving there. Exactly. Yeah. Okay, cool. and so- Just in terms of the, oh, one other thing, around making Lightning ubiquitous, right? So I know there are, obviously there are different standards in play at the time, at different times. One idea I've seen from Miles Puder of Cash App is this idea of Bit 21, and so it's like this idea of having, apparently it's quite an old standard, but like the idea is they're sort of doing it in reverse. They've got like a Lightning payment and an encoded Bitcoin address in there, and his idea is that, hey, what if everyone uses Bit 2 In the background, so the, the end user, like obviously if you're a hardcore Bitcoin and Lightning guy, you know, you love it, you're, you're fine with that, but the end, like the average retail end user who doesn't really understand, like the difference of Bitcoin and Lightning, maybe there's something there. But I'm curious, what are your thoughts on that? Do you see it like there are other standards out there, we're, we're not settled on this yet? Do you have any thoughts on making that user experience very seamless?" }, { "speaker": "christian_decker", "time": "43:31", "start": 2610.64, "text": "So it, it's, it's Since Vault 11 includes an, an on-chain fallback address. But, from experience, we found that, that sort of the behavior of, on-chain payments and off-chain payments are so different that you certainly don't want to have an automatic fa- fallback. Gotcha. so while, while I do agree that, that having an alternative way of, of paying for a, a transaction, be that on-chain or off-chain, and Vault 11 obviously uses, Uses the, Lightning payment as default and on-chain as, as fallback, and BIP twenty-one uses on-chain as default and could use other methods as, as fallbacks. I do think that, that we need to be very careful about when do we offer a, a fallback at all. For example, if I'm standing in front of a po- a point of sale and all I bought is a chewing gum, then I don't want to be surprised because now I have to wait half an hour for an on-chain transaction to confirm. Right. Yeah. and because- Because once, once we initiated that payment, there's no turning back, we, we can't, we can't really abort, in, in mid-session. And so that is, that is something to be aware of. But I totally agree that, that providing, a full matrix of different payment options is, is definitely desirable, so that users can pick and choose what, whatever works for them. And if none works, well, we're falling back to what we already had, right? The fir- the, the single payment didn't work, Yeah, it's, it's not worse." }, { "speaker": "stephan", "time": "45:08", "start": 2707.71, "text": "Yeah, and it, it does get challenging, because of having to deal with different scenarios, right? So as you said, if it's a chewing gum, maybe it's a dollar for that chewing gum, you're not really gonna pay a dollar or even fifty cents on-chain transaction fee for that. So maybe in certain cases, it would have to be restricted to say, \"No, Lightning only. We don't wanna do any on-chain below a certain value,\" but then above a certain value, it might be like, \"No, on-chain Yeah. Yeah. For," }, { "speaker": "christian_decker", "time": "45:37", "start": 2736.77, "text": "for, for this kind of trade-off, we, we have, we have introduced, the idea of a fee budget in, in core Lightning, and, what we do is basically we compute zero point five percent of the, of the to-- tr-- amount to be transferred, we allocate to, to a fee budget, and inside of that fee budget, we do a number of optimizations that, some go towards improving payment efficiency, we're looking into, into pickard payments For example, those might not end up being the cheapest ones, but the ones that, that have the highest success rate, and we also use, some of that fee budget to, to obfuscate, payments, for example, to add shadow routes, to sort of fuzz the fees at, at various points in, in the payment. And the idea behind that is, is obviously that, there should be, there should be a percentage below which the user really doesn't care. There's other stuff That is more important, like their time to completion, and, a similar concept could be introduced for the fallback on-chain, payments as well, where you say, \"Hey, all I'm interested in is speed of completion or, low fees, but I, I don't care about the exact fees. They don't have to be optimal or minimal in, in, in that sense. I, I have a certain experience that I'm looking for, and please provide me with that payment experience.\"" }, { "speaker": "stephan", "time": "47:06", "start": 2826.35, "text": "Yeah, that's cool to see. I am hopeful, like, I think one interesting stat, and, like, I think part of it comes to education as well, because there was an interesting stat actually, I saw Matt Alborg from Bitrefill pointed out, like, he was-- I think he was looking through some data and seeing that out of all the Cash App customers of Bitrefill, as in people with the Cash App paying Bitrefill, that apparently even though Cash App can do Lightning payouts, only one third of the users were using Lightning, so for that. So, I So on Bitrefill, like at just as an example, right? And if it's already at that point where, let's say, all these users could be using Lightning and just massively faster, smoother experience, lower fees, you know, it's an educational thing, but also maybe a technological thing as well that as a community, that, you know, as the ecosystem of businesses, developers, and like advocates have to think about that, right?" }, { "speaker": "christian_decker", "time": "47:58", "start": 2878.34, "text": "Yeah, it's, it's definitely chicken and egg problem, right? For, for vendors to, to show Lightning prominently, there needs Sufficiently large user base, and for there to be u-uh, sufficiently large user base, there has to be enough awareness that, the seller actually accepts Lightning too. So I think we'll eventually get, get that breakthrough, and I see awareness of, of Lightning payments and their advantages, but also their disadvantages growing over time." }, { "speaker": "stephan", "time": "48:27", "start": 2906.7, "text": "So I wanted to chat a little bit about any prevout as well, just to, you know, get an update from your thoughts. I mean, last time we spoke, it was, it was a while ago on this, You know, about any prevout, could you give us a, a bit of your updated thoughts on where any prevout is at in terms of, you know, development and thinking?" }, { "speaker": "christian_decker", "time": "48:45", "start": 2924.95, "text": "Yeah, so, it, it wouldn't be an episode with me without chilling L2 at least once. and for, for us to get L2, we need something that provides us with the base functionality, and any prevout is exactly that base functionality or is one way to achieve that base functionality. At the moment, the, the The proposal itself is, is quite well reviewed. It has, it has been, merged since, since AJ Towns, re-uh, ported it over to Taproot, which is also when the, when the name change, from SegWit No Input, which was my original draft, changed to, Any Prevout, or Any Prevout Any Script, which is a much better name, by the way, SegWit No Input really was confusing. And, so the specification is Are some, experimental implementations of it, in branches both by AJ and, Richard Myers, and Richard Myers has built out a, working example of how L2 could be built on, on this branch. so we are seeing, we are seeing that, any prevout is, actually fulfills its promise of enabling L2. I was pretty sure about that, but it's always nice to, to have confirmation of that. And, we are basically, looking into different, different, ways to make use of any prevout beyond L2 So technically speaking, if any prevout were merged, we could have the base, base L2 system working onto which then different, different enhancements and improvements are stacked on top. But as it is, any prevout would give us that. And ever since, Jeremy came out with, OpCtV, we've also been looking into, into his, his use cases and see how they interact with any prevout. And some of them are interesting enough, we can, we can build out some of, some of these use cases using OpCtV. So that's something that I didn't expect, but, but for example, we can, we can reconstruct some- form of covenants, using, using any prevout and, the non-recursive ones, the non-controversial ones, I should say, and, we can also build a form of congestion control, which is something that Jeremy has, has proposed. So there is a bit of overlap between the two. sadly though, opctv alone doesn't enable L2. for that, we would need another change called Object Sign From Stargate. Which, if I remember correctly, is a bit more controversial. But hey, if, if we, if we can get, if we can get the functionality we need for L2, I don't care if it's called APO or CTV plus CSFS, so a-as long as we, as we get, we get what we need to make progress here." }, { "speaker": "stephan", "time": "51:45", "start": 3104.94, "text": "I see, yeah. And also, as I understand, there's been more discussion on the mailing list and things, and I think even in the last episode we spoke a little bit about it, but if you Explain and understa- like help us understand a little bit about some of these ideas, like, like a pinning attack and layered commitments. Well, let's start with pinning attacks. So if you could just help us understand what is a pinning attack in, what's the, I guess, the significance of this in an L2 context?" }, { "speaker": "christian_decker", "time": "52:12", "start": 3132.08, "text": "Yeah, so pinning attacks were something that, that we found in while developing anchor outputs for, for Lightning. And the idea is basically that if we have some malleability in the, in the transactions, namely that, if the two of us, for example, manage a channel together, then they are first party malleable in that I can, I can change some parts of, of this, of this transaction, and you can change some parts of this transaction. And anchor outputs increases the malleability so that you can have a child transaction attached to, to one of the outputs. And if you then take this, take this bundle of the closing, transaction for the channel plus the, plus the child that is paying for, for fees, and make that child really big You end up with a bundle that has a, a gigantic fee, but a very low fee rate. so, it might be ten kilobytes and it might have ten kilosatoshis attached to it, so one vbyte per byte, but the overall fee is ten kilo- kilo- sat, so, so that would position that transaction very low in the mempool, itself, so it would be very unlikely for, for a miner to pick it up. And, and included in a block. But nevertheless, it, it is sort of tainting the mempool, in that if you perform this attack and I wanted to sort of fee bump my, my version of that transaction, whoever sees first your transaction and then my transaction would basically say to my transaction, \"Oh, you don't have enough, sufficiently, sufficiently large overall fees, maybe despite my transaction paying twice the fee rate, right?\" Simply because for us to make a replacement, both the absolute fee and the fee rate has to be, has to be beaten basically. And then people were, were, were sort of, take-- picking up my chant, of, of, of saying, \"Yeah, L2 fixes this,\" and one voice was missing, and that was mine, because I then had to turn around and say, \"Nope, this is also true for L2.\" So that, that was indeed a sad day. The good news here is that we, We have a very large number of, of ideas on how we can fix it. The problem with many ideas is also that, there is a lot of competition as always. So whose idea is, is the best and, what, what are the downsides of each individual, idea? So, there are, for example, people who are proposing that, that in, we should sort of separate the mempool replacement logic into different, different concerns because That fee rate bump is what miners really care about, right? if I have a transaction that pays me more fees for the same number of bytes, hey, I'll take the one with, with more fees, right? whereas the absolute fee, rule is more of a denial of service, protection where we could have an attack of somebody creating a huge transaction which with tiny fees but just enough to be relayed on the network, and then once, the next second they shave off One byte, therefore they have a higher fee rate in absolute terms, and they could send it through again, and that, that is basically prevented by requiring a, a bigger overall fee. and the ideas, and, and one of the ideas is basically to say, hey, instead of looking into the fees to decide on replacements, we could rate limit what, what peers can send us. So, you, you're my peer, you just sent me, ten kilobytes of transactions, now I want Will accept the next transaction from you, only after a certain, certain period of the cool down period basically. But as always, the discussions here are a bit, a bit more complex and, lengthy. Right." }, { "speaker": "stephan", "time": "56:21", "start": 3381.24, "text": "Yeah. And what happens is, at least from what I can notice on things like mailing list discussion and online discussion, is sometimes if there's not one clear winner, then people just spend all day, just constantly arguing about this and that, and there's not really like a clear kind of, \"This is the path forward.\" And then sometimes- Things happen, sort of fall into a gridlock, unfortunately in some cases." }, { "speaker": "christian_decker", "time": "56:43", "start": 3402.87, "text": "It, it has to be said though that this is part of the process, it is very important for us to basically have this time to stew over different ideas and sort of, think about all of the different things that might be impacted by one, proposal, or the other. And so I, I think this, this sort of lengthy discussion and lengthy process to- Actually reached a conclusion is, is a feature in this case. This is, this is not a system that, that we want to change willy-nilly. This is something that, that we want to keep for the next hundred, two hundred years up and running. So what's an additional year, compared to centuries of, of uptime?" }, { "speaker": "stephan", "time": "57:26", "start": 3445.94, "text": "Yeah. And so what's this, layered commitment idea?" }, { "speaker": "christian_decker", "time": "57:31", "start": 3450.87, "text": "So the layered, commitment idea is something that AJ Towns came up, very pro-- a prolific researcher, and, the idea is that, we can cut down the waiting times for L2 in the worst case, a bit. Basically, the way that the transactions are structured in, in L2 is that we have an update transaction which sort of ratchets us forward, in the states, and then based off of that, update- The transaction, we have a settlement transaction which actually has the desired effects in the end, right? That there is an output for me, there is an output for you, and there might be an HTLC attached to it. Now, closing a transaction now incurs this, this two-phase close, right? We first send, settle, settle the channel itself by sending update plus settlement transaction, and only then we get to settle whatever is built on top of it, for example, an HTLC. I see. And all of this in- Includes timeouts in it, right? So like, like two hours of waiting time, six hours of waiting time, and so on and so forth. And that has the slightly negative effect of the timeouts of the settlement transaction and the HTLC summing up to a longer timeout. And what, what Layered Commitments does, it takes the, it takes some of the time-criticals, infra-structures and moves them not on the settlement transaction, but moves them on the update transaction. So as soon as the update trans- Transaction is sent to the network, we can already start ticking down the timers for HTLCs. There's a couple of pros and cons. The pro, of course, is, shorter timeouts, timeouts as in your funds aren't available for six hours until we have, we have asked the blockchain judge to sort of decide, hey, you misbehaved or you misbehaved. And on the, on the cons side is that it is a w- a much more complex, structure That loses some of what, what was attractive to, in, in L2, namely the simplicity and the cleanly, cleanliness of, of separation between concerns, because you're now moving the HLC back into the update mechanism itself, which is one thing that I tried my hardest, to, to avoid in, in L2. But, yeah, it's, it's an open discussion and, and we will, we will sort of reach a conclusion eventually, I guess." }, { "speaker": "stephan", "time": "01:00:00", "start": 3599.63, "text": "Yeah, gotcha. and because, yeah, like you were saying, there's various positives about that L2 aspect, right? It makes watchtowers much cheaper and easier to operate, it makes a whole bunch of other things easier. So it remains to be seen what happens there. And I think one other critique I've seen online is this idea that, oh, because L2 is changing the penalty model, so whereas currently in Lightning, there's this penalty model that if, let's say, I'm a bad guy, I try to cheat you, your penalty clause, you can, you can like steal, you Right. So there's this argument of, oh, in L2 land, you know, anyone can just try it, because at the worst, the other guy can only just publish the correct state, and you don't have like this sort of incentive or this negative incentive that you're not gonna lose money. But then I've seen discussion on this idea that, oh, you know, could they try to re-implement like a penalty model in the L2 sense, or would it be just more seen like, you know, keep the simplicity of L2?" }, { "speaker": "christian_decker", "time": "01:00:55", "start": 3655.6, "text": "Yeah. So, usually my, my" }, { "speaker": "christian_decker", "time": "01:01:00", "start": 3660.37, "text": "Penalties in, in L2 is that there is a small penalty, in the form of, of the, transaction fee that you use to basically try to cheat. While that might not, not be as harsh as losing the entirety of your funds, it is still a paper cut. And, if at the same time we can, we can reduce the chances of you succeeding by making watchtowers much, much more, feasible and much cheaper to operate, then we've basically achieved the same effect after all." }, { "speaker": "stephan", "time": "01:01:29", "start": 3689.99, "text": "Yeah." }, { "speaker": "christian_decker", "time": "01:01:30", "start": 3690.39, "text": "Risk is always, the multiplication of chances of something bad happening, in this case, you successfully cheating, which reduce by, basically improving watchtowers, times the, the cost of, of actually succeeding. Of this eva-event actually occurring, and in this case, by making it, so, so we've reduced the cost, but we've increased the chances of you being caught, and in the end, that, that can cancel out. As for additional penalty mechanisms built on top of, of L2, I think that is definitely a possibility, but it would reintroduce some of the complexity that we try to eliminate with L2 again, namely the asymmetry. We're sort of" }, { "speaker": "stephan", "time": "01:02:13", "start": 3733.46, "text": "unsolving the problem." }, { "speaker": "christian_decker", "time": "01:02:14", "start": 3734.96, "text": "Yeah, yeah, yeah. It's, It's, it's reintroducing a symmetry which then makes, makes it really hard again for, for multi-party channels, simply because if we have out of a set of n users, we have to be able to pinpoint who misbehaved out of this and then sort of distribute the penalty among the participants, it's not as clear-cut as it was in a two-party channel where, you cheated, I get your funds. With n parties, it becomes m- very much more difficult to, to discern." }, { "speaker": "stephan", "time": "01:02:44", "start": 3764.04, "text": "Yeah, right. And I think the- The simpler L2 model is probably what I would, what I would rather see personally, because at the end of the day, as you were saying, part of this is about scalability as well, right? Taking Lightning to the world, and we all know that current Lightning doesn't scale non-custodially to the world, right? Like this is just a-- everyone understands this. And so it's about what's the best way to make that more feasible, and I, I think that's probably the point to understand is that if we could get into this multi-party channel world, it actually makes it easier Custody, which arguably strengthens the system, but I, I also understand that, you know, there's big arguments, well, a-and, you know, some of that is fair enough because some people could say, \"Look, just no more changes to Bitcoin, right?\" There's the, let's say the Bitcoin conservatives or the, the ossification crowd, right? This kind of never change anything, like maintenance updates only, no changes, right? And I can understand that view too. So I'm hopeful that we, we can get the right kind of technology in that helps, but at the I'm curious what your thoughts are on the, the whole ossification crowd." }, { "speaker": "christian_decker", "time": "01:03:49", "start": 3829.7, "text": "Yeah, definitely. I mean, I've followed the Bitcoin project for the last thirteen years and, and I've seen it going from a very experimental thing where Satoshi one night just pushes some code and everybody just deploys it to this more rigorous approach of, of proposals, arguments, followed by reviews, followed by implementations, followed by tests, followed by deployment. And I think it's, it's only natural that, that for a system that, that had, that has gained this importance in our daily lives, we should be very cautious about what changes go in and what, what don't. And most importantly of, of all of this is probably that, that the process has to be slow on purpose. We cannot rush any of this, and we do have to give all of the, all of the proposals the, the sufficient time to stew, to get that feedback, to get people excited about it, to get people excited experimenting with it and, and maybe out of this discussion, then, then we find out a, a much cleaner, much nicer way of doing, doing things. For example, my, the, the AnyPrevOut, proposal, I would be absolutely thrilled if, if that were to be merged. But if something else comes along that gives us the neces- necessary functionality and that might be even more efficient than, than AnyPrevOut, it's a small hit on my ego, but it's- It's a huge step for, for the ecosystem as a whole because we then can get, get, get what we wanted to do, from, from the get-go, but in a better, and, and more efficient way. I haven't seen this proposal yet, but, but maybe it will come up. And, hence also my, my approach when, when proposing, any prevout, I, I wanted to have a very hands-off approach, and instead of trying to push any prevout, I wanted to get, to get people excited about the possibilities of what we, what we build on top of it, simply because the, the functionality we can get can't, maybe get in multiple different ways, and we shouldn't, we shouldn't concentrate on, on the name, on the tin- So to speak." }, { "speaker": "stephan", "time": "01:06:05", "start": 3965.74, "text": "Yeah, interesting stuff, and hopefully, there'll be, some discussion there. I think, I've heard, I heard an interesting characterization, the other day, Shinobi was on, with Citadel Dispatch, on with Rusty and with Matt O'Dell, and he was characterizing it like, it's, it's like this anarchic mob, and if you wanna change, you need to convince the anarchic mob they should take your change, right? Like at the end of the day, like, I mean, it's Users and the developers and the miners all want this, it's gonna happen. But I think what we see is maybe there's this discussion and it's difficult for the same person who puts it out there to be kind of the only promoter of it, that there needs to be enough other people who also really want this thing and they're willing to push for it. And so maybe that's what has to happen with any prevout, right? If, if people want it, then there needs to be enough people out there saying, \"Yeah, I want this thing, 'cause I want L2,\" or even" }, { "speaker": "christian_decker", "time": "01:07:05", "start": 4025.04, "text": "Yeah, definitely. I mean, it's what we want to get in the end and not how we, how we get it that is important, I think, and, and so it is much, much better to create excitement about, about applications, about use cases rather than the how we do it. We as engineers usually get very hung up on, on how we do it and, and the technical trade-offs, but as a-end users, it is much more practical for, for users to imagine what the thing that we enable by it is rather than the technical trade-offs that, that are required for, for actual Sanitair view in this case. But yeah, I totally agree with the anarchic mob, that, that's a, that's a very good picture. And yeah, let's, let's give people the time to actually make up their mind because there might be somebody asleep in that anar, anarchic mob, and, and when they wake up, they might bring the new, the new solution to the table." }, { "speaker": "stephan", "time": "01:07:57", "start": 4077.28, "text": "Yeah, well, let's see, hey, so, so let's, For, you can think of it like a training wheel for your core Lightning node, and the idea is you're a business, you're a interested enthusiast, a user, you can use it. and we spoke a little bit about, you know, the Lightning Network as well as, any prevout as well. So, do you have any closing thoughts for the listeners and, where can people find you online? So I'm," }, { "speaker": "christian_decker", "time": "01:08:25", "start": 4105.4, "text": "Snake on Twitter, S N Y K E, and, a c Decker almost everywhere else, and I'm always happy to talk about, about tech and, and some, funny things, about re- about Bitcoin and Lightning. I also like- Just talking about Lightning in general, to be honest. And, yeah, I'm, I'm really looking forward to, to, to seeing where, where Greenlight gets us. We hope that, that it builds, it builds a solid foundation for us, to, for app developers to build on, for users that just want to build, build out a, a prototype at hackathons, and of course, serve as an on, on-ramp for self-sovereign, for eventually self-sovereign, Bitcoiners, Learn, the ropes and get, get the expertise they need to move around in this world." }, { "speaker": "stephan", "time": "01:09:17", "start": 4157.61, "text": "Excellent. Well, thanks, Ian, for joining me. Thank you so much. Get the show notes at stephanlivera dot com slash three seven eight. Thanks for listening, and I'll see you in the citadels." } ] }