Bitcoin Transaction Pinning, ANYPREVOUT & eltoo

Hi and welcome to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by Swan Bitcoin. Swan has a new offer I'm excited to share with you today. This is for those of you who are US residents or taxpayers who want to hold Bitcoin in a tax advantaged way. Swan has an IRA, so Bitcoin is generational wealth, and you can now secure your bright orange future with the Swan IRA. Real Bitcoin, no taxes. Swan offers both traditional and Roth options to best fit your needs, create your IRA and start adding Bitcoin in less than one minute. Transfers and rollovers are available, and Swan's Bitcoin experts will get you set up with no transfer fees and no minimum balance requirements. This is real Bitcoin, not an ETF or other derivative. Get the real thing at Swan. Go to swan dot com slash IRA to see more details. For those of you interested in a community for Bitcoin builders, Build on L2 is a new community by Blockstream. This is an initiative with many community members, with contributors and companies who are building on core lightning and the liquid network. It's an interactive community platform where you can chat with other people and you can come together through various events which are being hosted like webinars, and there are also mentorship programs available to fast track your success, or you can simply explore the community space to learn something alongside other bitcoiners. So this could be relevant for you whether you're a product manager, designer, engineer, go and sign up over at build on L2. eltoo dot com. Now, when it comes to checking Bitcoin transactions, I use mempool dot space. It is a fantastic multi-layer explorer of Bitcoin. You can see Bitcoin's mempool, the blockchain, second layer networks like Liquid, and the Lightning Network. And with mempool dot space, you don't have to trust a third party. It's free and open source software. I use mempool dot space regularly to check my transaction fees before I send larger on-chain transactions. Now, if you are with an enterprise, mempool dot space has custom mempool instances with your company's branding. Can have increased access or availability in terms of feature requests. Go and learn more at mempool.space/enterprise. My guest today is Greg Sanders from Blockstream, he's also known as InstaGibbs. He is a Bitcoin and Lightning developer, and we're talking about a range of things ranging from transaction pinning and the mempool full RBF discussion, as well as transaction pinning vectors and possible fixes, and then we also get into some discussion about anyprevout and L2. So for those of you don't know AnyPrevout is a proposed soft fork which could help improve Lightning network and take us to Eltoo, which would be a, a much more improved version of the Lightning network. And we talk about what are some of the possibilities there con-contrasting Lightning network penalty, which is what we have today, with what we could potentially see, such as Lightning network symmetry. So onto the discussion with Greg. Greg, also known as InstaGibbs, welcome to the show. Hi,

glad to be here.

So Greg, I know you're doing a lot of work on some interesting Lightning stuff and transaction fee pinning things. I know you've been around for a while in terms of Bitcoin development and Lightning stuff, so yeah, interested to chat and hear a little bit more from your perspective and, yeah, wanna learn a little bit about what you're up to. So do you wanna just give us a bit of a high level, what are you up to these days? What's your main focus area?

Yeah, so starting last April 2022, I rejoined Blockstream, this time under Rusty, the core Lightning team leader, and, I've been working on, specifically was hired to work on L2, E L T O O, the kind of symmetric channel construction using any prevout or no input, soft forks. I was, I'm ultimately aimed at getting it deployed on, on the Liquid network, but as a key part of it, I'm building it for Bitcoin first, and then, you know, adapting whatever needs to be adapted for it since the, since the systems are so similar. Yeah. So that's kind of like the, the high level direction there.

Awesome, yeah. And I, I'm a, I'm a fan of the AnyPrevOut idea, and I would, I would personally love to see L2. So listeners, check out my earlier episodes with Christian Decker, where we've spoken a bit about some of this, and I'm sure Greg, you've probably pushed it forward as well yourself. And I know AJ Towns has also done some work on this stuff as well. so, yeah. Oh, and one other thing I was also curious to chat about, I know you have some knowledge or expertise in this area

So I think it'd be great if maybe you could just give us a bit of an overview of this idea, transaction fee pinning, like what, what is it?

Right. So this is related to the L2 work actually, because as I started working on it, I, I made, I wrote, the bolts, the standards for the L2 channels, and as I was writing these, I became more and more convinced that this issue called transaction pinning was gonna be a real problem. transaction pinning is where a kind of a griefer or a counterparty that is-- can accidentally do this as well, but they make a transaction that is unlikely to get confirmed anytime soon and actually is, so in effect, it's kind of not paying miners fees, right? And then you'd say, okay, well, why don't we RBF or, you know, double spend it with a higher fee? But due to a mixture of kind of design constraints of the current system, it makes it difficult or very expensive to do so. We can dive deeper into details on that, but that's high level kind of. Miners aren't getting paid when they should be.

I think it'd be good to chat a little bit about that and, you know, if we could maybe put that into a context, like, let's say you and I had a lightning channel together, and let's say, so I guess for listeners who are like more newer to this, like the idea is we have pre-signed transactions that aren't broadcast yet, and so I guess the idea is if one of us goes offline, if the other has to now Broadcast that transaction, right? But I guess part of it is like, the-- we're getting into this idea of if, let's say, I'm malicious and I see you've gone offline, I try to, you know, broadcast a, an old state that has, you know, less coins for you and more coins for me. And so I guess could you just talk us through what that would look like if, let's say, let's say I'm malicious, I'm trying to stop you from putting in your justice transaction or your penalty transaction?

Yeah. So I think for pinning the specific We'll talk about are as, delaying out the HTLC resolution, so a hash time lock contract, which means your-- this contract is supposed to be resolved within N blocks, you could say like a day's worth of blocks. But what happens is the timer starts, so the commitment transaction, this lightning transaction hits the chain, this timer starts, and then what the counterparty can do is make a transaction that's kind of very large and low fee rate. So if there's a fee rate spike, if there's a- There's a big backlog like we've seen recently, and the going rate's high, much higher than one satoshi per virtual byte. Maybe the counterparty can get that one satoshi per virtual byte transaction in the mempool, but not actually try to get it confirmed, and then this times out the contract, and then what they can do is they, they can take the time out clause of this contract and grab the money back. So for example, you already forwarded this hLc to another lightning peer, they've claimed it, but then the person that offered you the contract on the inbound direction, they claw it back. So essentially, you've been stolen from. And so pinning is one method of kind of stealing from you in smart contracts, or at least making your life difficult. There are other considerate-- So a less smart contracty thing is where, let's say you're, a, a Bitcoin payment processor. or you're a custodian, right? And you would do batch payouts, so you're, you're paying out to like hundreds of people at a time, let's say. One issue is that if you make a payout at low fee rate, someone can sweep one of their coins, one of the outputs could get swept by a, a, a recipient at a low fee rate, maybe even they do consolidation, right? So it's a large transaction, low fee rate, and then suddenly you can't RBF this transaction, right? Or even child piece for parent. So the tools for- being able to increase, to bump fee or trans- bump your transaction fee are reduced in these cases.

I see. So let me just walk that through to make sure I've understood. So let's say an exch- a big exchange is doing a payout for, you know, fifty customers and they're all getting their, in one transaction they're all getting, you know, let's say there's fifty outputs, but one of those customers, if he does a child pays for parent, but with a very low fee, you're saying that depending on the conditions at the time, that exchange Change is now no longer able to add more people to that unconfirmed transaction, or can, can you just walk me through that?

So basically this, let's say they did a very large child piece for parent, like they're consolidating for some reason, don't ask me why, this has happened in real life. Then what you do is, let's say you have a replaced by fee scheme for your payouts, now you have to pay for both your replacement as well as the child replacement. So if the child spent, you know, point one bitcoin on a very large low fee rate transaction, now you have to pay that extra point one bitcoin to replace that, 'cause you're knocking it out of the mempool, you're essentially taking money out of miners' mouths if you don't replace that fee, right? In, in a sense. And also you could say, well, why don't you just child pays for parent your own transaction? Like, let's say the payment processor or custodian has a change output, well, they-- you could just double, you could spend that output at a higher fee rate to bump it, right? This is called child pays for parent. But there can-- there's also called package limit pinning, which is another flavor of this, which is due to the complexity of the mempool architecture, there's a limited amount of both number of child transactions in a mempool Graph, you know, when you're tracing like, parents and children. And also, so there's, there's both count, so how many descendants in the mempool, and also how large they are total. So for example, one large sweep could just lock you out of the size constraint, so to say, you're not even allowed to spend your own change trans-- change output in the mempool.

So as I understand, I mean, these are things that just already exist today, so these are already limitations, so exchanges and pay- Payment processors and users today are just dealing with this today, right?

Yes. So I, I previously was the tech lead for the Liquid Network a few years ago, and this is a major issue because you can't-- you don't have a robust interface for doing replacement by fee or fee bumping. And so you're doing all these heuristics and guessing and saying, "Well, if we get stuck, that's too bad, I guess, and hope it resolves itself by luck, pretty much." I've also talked to other people who've worked on custody solutions, and this is a pretty common problem.

Right. And so I guess it's more of a problem if you are a large custodian or payment processor and you're dealing with these large transactions, like it's not typically just like an individual user who's, who's falling into these situations, normally, right?

Yeah, well, it's more normal where you have a motivated adversary, like in a lightning channel. So that'd be more typical from a end user perspective is you're entering to a smart Smart peer-to-peer smart contract, and you need to resolve a transaction fast. You need to get something confirmed in a jiffy, and there's people who have financial incentive to stop you from doing it.

I see, yeah. So then I guess part of this is also coming into that conversation a, a little bit around mempool, full RBF and things like this, because as I read some of the discussion, and you cl- you clarify for me if I'm getting this wrong, but as I understood, at one point or initially, it was understood that, oh, okay, having mempool Would help us sort of move into a situation where maybe some of these pinning attacks are less possible, but then later is sort of discovered that maybe it doesn't help us. Like, could you help us, you know, untangle what's happening there?

Yeah, so you can think of not having full mem, like the mempool full, full RBF. If you don't have that, that opens up a new pinning vector. Which is, is basically, in a coin join like situation with a peer, they can double spend their own input during like contract creation time and then, mark this double spend as not replaceable, so they get it into the mempool first and then you can't replace it, no matter how much fees you put on there. So that's kind of the idea, is that even if you put a lot of fee, you won't be able to replace it, efficiently. so yes, the alternative is well, even if we have full RBF, a motivated person can make it financially difficult to replace it, right? And they can kind of do this, so I think in the coinjoin scenario, it's for every input the attacker controls, they can increase the economic damage, so to speak, by that number of inputs, right? So it's- It's multi-multi-plicative. So while it doesn't fix pinning per se, it does remove one pinning vector. so it goes from like, goes from the you can't replace to, well, in the worst case, you can replace, but it'll be very expensive to do so.

I see. So i-it's fair to say then that mempool full RBF or just being in a full RBF world would help against some pinning vectors, but not all of them. Is that fair to say? Correct. Yeah,

exactly.

Okay. So it's possible to have pin context of this, even, even in a full RBF world. Yes. Okay.

Yeah. So one, one ex-mental exercise you can do is you can say, okay, look at the, the RBF rules, it's BIP one twenty-five. You just read, you read that BIP, look at all the rules that are there and say, how can this pin a transaction? 'Cause pretty much all of these are constraints on when you can replace something, right? It has to be signaling to replace, you have to replace the total fee. one example is you has a new unconfirmed input, which is kind of like esoteric, but there's all these like constraints you, as a wallet designer, you have to think about and take care not to violate to, to properly RBF transaction.

Right. And I think there are different arguments back and forth here, because as I understand some of the, let's say people who were anti the full RBF, they were trying to say, "Well, let us manage our risk," and then the people on the other side are saying, "Nah, actually full RBF is more incentive compatible for the long term, First scene should never have been like a promise that should be sustained forever. I'm curious, how are you seeing that debate, even though, you know, maybe it's a month or two, maybe three or four months old, but I'm curious how you're seeing that?

Yeah, so my take was, I did a lot of discussion with different developers, and there's different opinions, smart opinions on both sides, to be honest, but I do fall on the side of, you at least should offer the option of full RBF, mempool full RBF, because the Not have that feature is kind of paternalism and, and it just encourages people to run alternative implementations, which maybe it's what you want, but I don't think that's kind of the desire, right? So there's Prior to the release of, I think, Bitcoin Core twenty-four dot o, I think, that was when the debate was happening about like removing an option or not, and I was, I was vehemently against removing an option, even if I don't think it's the most burning question at the time.

Right, I see. And as I understand, one of the, let's say, anti-Full RBF arguments at that point from people like Sergey over at Bitrefill would be something like, "But remember, not every user is running a node, and there's lots of users who are just

In the running of a node, but I, I guess at some point the answer would just be that, well, ultimately if you wanna have a say, you have to run a node. Is that your answer or how would you answer that?

So with this kind of policy, you need something like ten percent of the network to run with the, with the option flipped on to really make a difference, and you need some, some percent of miners, right? Maybe one percent, maybe higher. So there's this kind of thing where it's, your actions alone aren't too important, but if there's a s-large minority of users that decide it's important and turn it on, then it may actually be an effect. So I think there's a bit of irony here in that I think some of the- The backlash was like, "Hey, you're trying to take an option from me, I'm definitely gonna run it now. " And that, I think, it's kind of the strawman effect, right? Like you're, you're drawing a lot of attention to it, and then that causes people to have a backlash Backlash. Now, I, I don't know what the number is today, I just think the future is going to be something like lightning payments. I mean, I haven't done on-chain for a few months now, you know, after I set up some channels. So, like, I think, I think that is the future, and everyone agrees it's the future, and that's partly why I'm working on lightning to make sure it is the future.

Right, yeah. And as I understand, there are different arguments there. I'm probably-- I think it seems to me, as I understand Or, or just the network acting that way, it seems to me like that's the, the world we're going into, and so hopefully more and more people are able to use Lightning and ideally in the self-sovereign way, which I think also gets into the ANYPREVOUT conversation as well, but I'm curious if you see it like that. Do you believe that eventually, even if Bitcoin Core doesn't, let's say, have it on as default, that eventually we would end up in some kind of similar scenario, or at least you see, you, you

Yeah, I think that's likely, especially when you consider a lot of the popular node software now, it comes pre-packaged with its own configuration, right? And you just need one kind of popular, for like Umbrel or something, you know, those popular distributions, where they would flip on that switch themselves, so it's not even really up to Core per se, right? It's up to basically what people are running, you know, the, the node runners themselves are in charge, so it's kind of an open question, and I think long term, I just think it makes Sense.

Yeah. And I actually on that point, I think it was interesting seeing some of the arguments there back and forth, because some of the arguments were, "Look, yes, there's a lot of people who are signaling RBF manually in the, you know, in the current regime, but not a lot of people use the RBF." That was one of the arguments, right? It was saying, "Uh, and I guess the argument could also come back, well, maybe a lot of them don't know how to, maybe they don't have a wallet that enable-- that is enabled for The longer term is using Lightning, of course, and of course, many of the people on both sides of that debate are pro-Lightning, but I just thought it was an interesting one to understand. And so I guess bringing it back to the pinning aspect of it, do you see, I guess, as, as we were saying, even in a full RBF world, that takes away, I guess, some of the pinning vectors or one of the pinning vectors, that's right. And then what are the other pinning vectors that remain and should we be worried about?

Yeah, so I think I briefly mentioned them, but I call them kind of, 'cause like, there's more than this, but I would call the major two are, packet, we call it Rule Three Pinning. This is Bitcoin twenty-five Rule Three, which says you must replace all the total Bitcoin fee Right? The total fee of everything you're going to knock out of the mempool with your replacement.

I see.

So if the, the descendant is huge and low fee rate, it doesn't really matter because you're paying the total fee. So it can make an out-- So if your, if your transaction size was going to be a thousand bytes, one kilobyte? They could put in a child transaction that's a hundred thousand kilobytes, and so essentially they're kind of inflating the size of your transaction by almost a hundred times, right? If you can think of it that way, they're making this whole package a hundred times larger and then reducing the fee rate down to something that won't get confirmed.

I see. So that would allow them to indefinitely pin something to the bottom of the mempool per se and stop it from getting confirmed through. And in a Lightning context, that means somebody could lose money, right?

Exactly. In a Lightning con-- it's more interesting in things where there's timeouts involved, right? The time value one was, if someone pins you and it just inconveniences you, that's annoying, but no one's losing their job over it, like at the custodian level, right? But at the Lightning level, it's real, it's a money loss situation, so it Then the second, the second largest kind of pinning vector is package limit pinning, which I mentioned, which is basically in the mempool by default, a packet, a transaction can have up to twenty-four descendants, so twenty-five including itself. also in a mempool package, it can only be up to a hundred and one kilo virtual bytes. So with a SegWit transaction, that's up to almost four hundred kilobytes, right? As we saw with, the ordinal stuff. so a child could just be like too large. And then, so if you're trying to spend your change output to bump the fee, that stops it from happening. So that's kind of the other direction there. If you want a child pays for a parent, the package limit pinning stops it. If you want to replace by fee, by double spending it, then the one twenty five rule three makes it economically, expensive, may-may-be uneconomical to do that.

I see. And so is any of this impacted then? I know Gloria's working on this idea and maybe others, maybe yourself, on this idea of mempool, package relay. So is, what's, is there an interaction there? Like, is that Stopping any of this stuff?

There is, there's a light interaction. So today with Lightning contracts, the, what's called commitment transaction, which is the thing you're, you're signing and replacing con- constantly, this has to have a pre-agreed fee rate, which you expect it to get into the mempool at all, right? Because let's say you do one Satoshi per virtual byte for the squirming transaction, then the min rate goes to two, right? We saw this just last month. So in this situation, you would not be Able to get the commitment transaction in the mempool at all, right? That's a problem. So package relay is this notion that, well, if we could tell nodes about the parent and a child, just as a simple example, so the commitment transaction and then a spend of what's called an anchor output to bump the fee rate, if you could tell a node about both of those at the same time, they could, they could evaluate it together and say, okay, I think this can make it to the mempool because I think a miner would want this as, as a package. And so with package re- so if you just do ba-basic package relay, then what we can do is for the commitment transactions, we can drop those to zero fee. We say, "You know what? Ahead of time, we don't know what the fee rate's gonna be for the mempool, so let's try not-- let's not even try to guess." So what you do is you have the parent transaction be zero fee, and then you have the child pay for the entire package out of its own pocket, so to speak. Does that make sense?

Yeah, I think I'm getting you

Miners and the network see, oh, there's actually a little bit more fee associated for this, so I'm gonna take this one, whereas previously it might not have had enough fee for me to be interested. Is that kind of how-

Correct. Yes, that's right. Exactly. Because right now you have to individually send transactions and evaluate the fee rate individually, right? So that's, that's the, that's the problem here. So with Package Relay, we can simplify these, we can simplify the Lightning Network a bit, but you still have these pinning scenarios, so I can jump into So you still have the rule three pinning, the kind of economic pinning of the total transaction fee issue, and you still have the package limit pinning. But this is where, Gloria and others have been working on the version three proposal. If you wanna jump into that?

Yeah, sure, let's talk about that.

Okay, so it's very difficult, you know, I mentioned all these big numbers, you know, a hundred one kilo kilobytes, I mentioned twenty five descendants, and this descendant graph is like hard to reason about because every tr-transaction can have multiple parents. multiple children. And so this like, these algorithms that are there to help the miner get the most fees and the algorithms to make the mempool like, down to size when it gets too big, these are kind of different algorithms and they're hard to reason about. They're kind of in conflict with each other in some ways, and they're hard to reason about. So the version three idea is, what if a transaction can opt into a new kind of regime where it's simple, right? Simple to reason about. So the V3 proposal is, what if You, you pick transaction version three, and that means there can only be one parent and one child transaction, so a package size or a package count of two transactions. And they have a strict relationship, and from there it becomes much easier to reason about, for example, package limit pinning and all these other things. In addition, the child is restricted to one kilo virtual byte.

I see, so that would stop the rule three pinning.

Yes, that's the-- so that's for the rule three pinning. And so I call this also, I call this like an RBF carveout because it lets you R- i-in the cases where you want to RBF or can RBF, then it becomes do- like much more doable So let's, let's go back to the lightning case. Let's say we've adapted these commitment transactions to use this. Then the commitment transaction can be any size, like it is today, and you're pre-agreeing with your counterparty, you're saying, "This is a new channel state, this is a new channel state." But then when it comes time to go on chain That hits the chain at zero fee, right? This commitment transaction zero fee, and then the child, one of the anchors, the-- there's two anchors, one for each person. One of these anchors will get spent, and it'll be small, therefore you're basically ensuring that the rule three pinning is up to one kilobyte, right?

I see. So we can think of it like it kind of contains the rules or contains it into certain known pathways, and then that makes it easier for us to do Lightning and to do maybe other protocols as well, maybe not just Lightning, right?

Yeah, exactly. And so actually, I think the proposal would be that, each version of the commitment transaction, since I have a copy, you have-- like, let's say we have a channel, I have a copy, you have a copy, these are separate pre-signed copies, we each have only one anchor on each transaction, we have our The one we'll broadcast, we have an anchor for ourselves. And so then we can package relay rbf each other. So I spend from mine, and I put both of those in the mempool, then you can respond with a newer version, right? Yeah. You can package rbf, and you don't even have to look at the mempool for this. You just, you're picking a fee schedule. You know, I think this is a good fee, and I need to go to chain, and you can blindly double spend this. And that's the important part, is that these wallets don

packages and, you know, outbidding the other person. That's the important part.

Yeah, interesting. Okay, so, yeah, and this is kind of all leading towards this idea of, well, what, what are we gonna do with Lightning? Because some of this stuff, as you're saying, it's already a risk, like it could already happen, it's just that some of these ideas are being designed to stop this in the future. So I guess it's kind of like trying to preemptively stop this stuff happening in the future, where, where in this scenario where people not safe in Justice transactions confirmed because of these fee pinning or, sorry, transaction pinning, vectors.

Yeah, and, and we've also had a long period of fairly empty mempools, and this issue doesn't show up unless the mempools consistently backlog or maybe suddenly gets a big backlog of high fee rates, right? Yeah.

Yeah. And so for, for a lot of people, they've just kind of become accustomed to it or, in some cases, they've shifted to altcoin chains. And maybe we've seen this historically with, you know, Omni, Tether came off- Bitcoin, and then a lot of the stable coins went to shit coins, right? They're on Ethereum, Tether and Tron Tether. And so people just, you know, and exchanges did batching, and most people are using SegWit nowadays, so it's kind of, it's taken a lot of what was previously the fee pressure or the block space pressure, right, off the chain, but it could come back, like if we saw a big uptick in users, then all of a sudden we'd be back in that same environment, right?

Yeah, or s-s-or lots of people You need to be able to react to this, because a counterparty could just be sitting there waiting and say, "Aha, now the mempool's backlogged," and then do this attack. So it does actually matter. It's like a future security argument, even if the mempool's mostly empty in general.

Yeah. Right. Because they could be opportunistic about it right now. Yeah. Yeah.

So, so let me spin the thread a little bit more. So we have the version three proposal, which is being worked on, and package relay, which is being worked on. So V3 Quite solve this, the situation where you have the package limit pinning, at least in general. So the package limit pinning issue is still there, right? If you want to child pay your parent by spending your own, let's say, change output, the counterparty that has a spendable output in the same transaction can basically max that out, right? And disallow you from spending, doing a child piece for parent. And so this is where I've been working on a proposal that kind of extends V3, which is called Ephemeral Anchors. Which is this idea that, you can attach an output that doesn't require any signatures or anything. So in this case, it could be an OP_TRUE output, basically a, a, a bare OP_TRUE output that That is zero value or can be zero value, that is essentially a hook, like it's like a lock on the transaction, where to get this transaction in the mempool, you have to spend that output. So it's essentially like, you can think of it like a, a lock on the tran-- on, on this transaction where, yeah. So if it has other outputs, let's say, let's say you have, two outputs and this anchor. Then a counterparty can only spend the other outputs if they also spend this special output. Does that make sense? Basically, because you have to spend it, it will be spent. And there's only one child, if, if you remember this, that, in this V3 regime, there's only one child, so they must be spent together. And so then that makes it kind of like a lock on the, on the parent transaction, says, "Well, you have to spend this," so anyone can double spend these, these, child payments, essentially these child spends. And so this, this kind of unlocks the, the package limit pinning scenario where in the commitment transaction, in the original commitment transaction that has two anchors, you can't get pinned because the, the, the outputs have to be spent together essentially. Along with this ephemeral anchor. interesting. So it's a little hard to, yeah.

I guess it's hard to conceptualize, but I, I think I'm sort of following you. Yeah. and

I'll give you a specific example right now. So if we wanna do like, splicing, right? Or make a channel. All of the smart contract scripts have this thing that is a, a one block relative time lock, a one block check sequence verify. All of these outputs have them, except for the anchors, and this is because we're trying to stop package limit pinning. Ironically, this can be, this sometimes can be incompatible with Miniscript, and it also means you can't do smart things like, "Oh, I want to splice into a new..." A new channel funding output, but also not pin the other person, right?

Back to the show in a moment. When it comes to securing your Bitcoin for the long term, you know, I'm a big fan of multisig and Unchained Capital can help you out here. They have multisig that is secure, transparent, easy to use, and sovereign. With their multisig, you generally hold two keys in different locations, of course, and they hold the third key, so they can help you in the case of recovery. They can also help you out in the case of inheritance. So, Conse Onboarding is a program they offer. You can pay upfront, they can ship you some hardware, they'll do a call with you and teach you how to set this up, even if you've never held your own Bitcoin private keys before. They also have some inheritance step-by-step checklists, letters for the executor or trustee, and a range of other support and education. You can find all of this over at unchained dot com slash concierge, use code livera for a discount. And when it comes to hardware to secure your Bitcoin, coinkite dot com offers a fantastic range of products here. Coldcard Mark IV, the latest edition. It has two secure elements, it has NFC support, but you can of course disable that and just use microSD or USB if you wish, and it has more RAM and CPU for faster signing of transactions. It's also a very reliable performer. I found it really reliable and, and I really like that you can set up this device without even plugging it into a computer. You can just plug it to the wall, or you can even battery power it and use it in that way, and then you can set it up easily with wallets such as Specter Desktop, or Elektron, and CoinKite also offer a range of other products, notably the BlockClock, SeedPlate, or the TapSigner, a range of other products you can check out there. Go to CoinKite dot com, use code Livera for a discount on your cold cards. And finally, for those of you looking forward to a Bitcoin event, this is going to be the biggest Bitcoin event in Europe, it's BTC Prague, it's happening in Prague, Czech Republic, June eighth to tenth. This is going to be a fantastic event, I'm excited to go, I will be There'll be so many Bitcoiners, so if anyone is in Europe or near Europe, definitely check your calendar, check your diary, mark, mark this out, get some flights, look at hotels, do those things now because you wanna get in for this one. There are a range of tickets available, whether it's the standard ticket, the industry ticket, or the whale ticket, and you can get increased access to the whale zones with a stylish environment for networking and meetings. There will also be white glove service and premium food and drinks for those of you who wanna get the whale. L ticket, as well as an exclusive party event, so go to btcprague dot com, use code livera for a discount on your tickets. And now back to the show with Greg. Okay, yeah, so it's, so I guess it, it comes down to protecting against package limit, pinning may also stop some of the extensibility of other features like splicing and so on.

Exactly. So you're adding on these extra ad hoc measures to stop pinning, but that breaks composable with other smart contracts and, and whatnot. So So you'd love to splice directly to your, like, your Coinbase account or whatever, right? But to the counterparty, you might have to prove to your counterparty that, hey, this, this script has, you know, I can't, I can't pin you in the package sense, right? Package limit sense, right? But how do you prove that, right? Maybe it's not your, you know, it's, it's Coinbase, it's not even your address, right? Maybe they have committed to, you know, a Taproot script of whatever, but we don't know Look at them and say, "Oh, does it have a time lock on it? That breaks a lot of things, I think." So that's, that's another idea. I

see. So that's kind of just an open question at this point. And I guess, does that conflict then with splicing in general? Does that mean we won't get splicing if we have a free- No.

So, so I think splicing is a bit of a red herring. I was just using a motivating example in that, as long as the commitment transaction can go to chain, you're okay. So let's say you do a splice and your counterparty pins it, right? They make a bunch of stuff off it. Well, in the end, you're supposed to be collaborating with this person, and you have a commitment transaction that can go to chain at any time, so you're okay. So there's like, you, you really have to sit there and think about all the situations that can arise based off of the things you have signed. So it, it complicates things more. But the ephemeral anchors would mean that in a kind of composable way, you can say, "I don The, script like format of any of these other outputs are, as long as there's one of these anchors on the transaction, I know I can double spend it essentially. So, so I can tie this into kind of I've been working on an L2 specification for Lightning, and based on this, I can remove a lot of things that are complicated, so I don't have to add any time locks to any of the, any of the script outputs, except for, of course, the, the contract timeout itself, like waiting like the con-contesting period, right? So We have to, I have to wait a day to claim my funds because I might be lying, right? They can come back online and, and put the latest state on the chain. So aside from that, I don't have to add any time locks, any of the outputs in any of the transactions can be spent immediately to include fees, right? So when you're settling the, when you're settling the, the state, you have like your balance output That's coming out of it, right? You can immediately spend that as a child pays for parent. Today you can't do that, right? So when you have a commitment transaction on chain, the only thing you can spend is the anchor, which means you have to bring your own fees always. So It simplifies like the, the wallet complexity and how much funds you have to have sitting around to settle these smart contracts.

I see, yeah. Okay. So could you outline a little bit then, so just for people who aren't familiar, like what is any prevout like in kind of simple-ish terms, if you could explain that, and then just, I guess, summarize the benefit for L2?

Okay. So any prevout is, an evolution on a proposal that's been around for a while called no input, and basically it says normally when we sign a transaction, we're putting, you know, we're making a hash like a, called a commitment or like We're including all the important transaction pieces that we say the signature attaches to. Any prevout basically says, "Well, sign the same stuff, but don't sign which output specifically this is coming from." So, that's what's any prevout, previous output. So any previous output works for this signature. So what the checks will do is say, "Uh, is the lock time correct? Are the outputs correct? Some other details, but it won't look at..." The previous output identifier, so like the TXID and the output number, it won't look at that. So what you can do is, you can sign a series of transactions, then these can be essentially re-rebound to any previous output that makes it onto the chain. So for L2, this means there's a funding output, so where you both put funds in at the same time to start your channel, and then once someone goes offline, you can basically put the last version of the signature you've had Had on chain and rebind it to that output, right? If an attacker, if, if a counterparty puts an old version of this, of the channel on chain Then you can rebind your latest version to the output they just created. So essentially, you're building this chain of state outputs, and any of the newer state transitions can attach to older ones, any older one essentially.

So as I understand, and, and I believe this is the way Christian Decker explained it to me, is that it's like a ratcheting effect that, let's say, I publish an old state, you can-- you're allowed to publish any newer state, and yours will be re-regarded as the correct, you know, that's the one that would get- Confirmed into the chain.

Yeah, so like the hundredth channel update can spend with the ninety-ninth one, the ninety-eighth, and, and so on and so forth, all the way down to the orig- original one. And so that means your overall node state is constant because you have to hold one or two versions of this, in my spec, you have to hold two versions of it, so you'd have to hold the hundredth and the ninety-ninths in memory or on disk or something. And also for watchtowers, it's, it's the same. A watchtower only Transaction.

Yeah. So just to summarize then, the idea with any prevout is there are these sig hash flags and they relate to what the signature is committing to. And so in the any prevout context, so I guess typically we would just be in a, let's say if you're just in a normal Bitcoin on-chain wallet, it's just sig hash all, right? Or it would just, that's like the typical-- Usually, yeah. Yeah. And then in the any prevout context, you'd be having a special sig hash flag which lets you- You re- and this is the re-binding concept, right? So it's saying, "Let me rebind this input, right?

" Exactly, that's exactly right. So you might do sig hash all any prevout, which means I'm committing to all the outputs, but I don't wanna commit to the previous outputs. Right? And you can do SegWash single, which is I'm, I'm committing to one output but not the input, right? So t-there's these combinations that you put together depending what you want. So I use, I use any prevout, the, the version that I use is called any prevout any script, which also means it doesn't commit to the script that you're executing, so the TapLeaf script. And it also doesn't commit to the amount.

I see. And so, is that going to vary also across script type, or are we fully in a Taproot world here?

Bip one eighteen is only defined under Taproot. So it uses the unknown public key extension hook, which means if there's a public key, when you do a check sig operation in, in Tapscript, if it has a public key, if the argument, the public key argument is not thirty-two bytes, today, it would just say Success, say, okay, the signature passed. Bitcoin 19 redefines two, two different lengths. The length of one, if it's one byte long and it's the number one, then it considers it the internal public key, so the Taproot internal public key, which we, you can define that. Or if it's thirty-three bytes and it was a leading one, then the last thirty-two bytes are considered a normal public key, normal taproot like, public key for check sig. But it, it turns on this new sig hash mode. So if it has a leading one, that means you're allowed to do any prevout for that key. You don't have to, but you can.

Right. Yeah. And so that's the, I guess that's the other part where it's opt-in, right? Like people don't have to use any prevout if they don't want to, right? Like that's, I guess that's an important concept for people to understand.

That's right. And it won't be activated for key spend when you're, when you're doing a top level spend. So, you know, ninety-nine point nine percent of the time you wouldn't be using it. It's used for these very special smart contract

That an L2 context or just moving to L2, E L 2 O O, it would make backups a lot easier, it would make watchtowers a lot easier, and it would also enable this concept of multi-party channels, right? Or in future?

Yeah, so the spec I have written now is for two-party, but it was written, at least the transaction structure is written with an eye for multi-party. So given version three, ephemeral anchors, and Bitcoin eighteen, and package relay, these like concepts together, you can- Can fairly, you know, fairly trivially expand this to multi-party. There's trade-offs of course, and the peer-to-peer messages would have to change a fairly significant bit But I think the, the parts are there and it can at least be considered. I mean, it might be a good intern project or something to work on that. but I'm, I'm focused on the two party case for now, just seeing, you know, implementing a spec and actually implementing it in core Lightning has been my work for the last, you know, last almost a year now, and I'm just pushing that ball forward.

Right. And so could you spell out the difference for us in the models of LN penalty and the L2 way? Whereas I understand we might be taking away the penalty and it's more just updating to the correct state as opposed to having some kind of a penalty.

Right. So the Lightning Network today, some of those developers call it LN penalty, which means a Lightning Network penalty based channel, and this is the idea where, you have a punishment where if you put the wrong version on chain, intentionally or not. All the balance can be taken by the counterparty, right? This requires asymmetric state, meaning each of us need a different version of a transaction, or at least different witness data, usually different state data, and you have to track this in perpetuity. There's another version of it called DARC, D A R I C, which is an ANYPREVOUT based penalty channel construction for two parties. So it would get you a lot of the efficiency improvements that we've been talking about, these O of one state efficiency improvements Improvements, and but it would re-retain the 100% penalty. The one I'm working on is dubbed LN symmetry, 'cause it's symmetric state, right? So you have this symmetric channel state, symmetric transactions, and it has no penalty, because since it's symmetric, there's no way of ascribing blame, at least mechanically, right? if a, if a transaction shows up on chain, either of the counterparties could have done that. There's also in-between, versions as well. So Anthony Towns had a, has a proposal adding in, you know, optional penalties to optimizing for the two-party case, and you can add in penalties if you want, and these could be partial penalties. You could do a percent of the channel balance, a constant size. you could penalize just the HLCs outstanding, things like that. So it's like a, a parameter you could set, but it's a little more difficult to add in watchtowers. You can do it, but it re-adds some of the complexity you're trying to avoid, you know, 'cause you don't want a watchtower to basically play an old state that penalizes you. That's kind of the key.

I see, yeah. so yeah, s-- to me it sounds, I mean, I understand there may be some people who, who want the penalty aspect because they believe that helps stop bad actors, let's say. but maybe on the other hand, if we have it in a way that's symmetry, like the LN symmetry model, it's arguably more scalable and a little bit easier f-- to transition into, let's say, the multi-party channel future, hypothetically, right?

Yeah. So without penalties, the multi-party scenario is pretty simple to think about. You do all people You know, the most naive construction is all the parties have to be online to sign new versions of the transaction, which may or may not make sense depending on what your channel partners are like, but it does mean that watchtowers become a lot, kind of safer and, I think the, the incentive here in a, in a, pen-penalty-less world would be that you want to be online, and your counterparty will want you to be online because that's the cheapest thing to do. If watchtowers are plentiful and it's easy to get a, correct version of the transaction on chain, basically your counterparty will be incentivized to reach out to you and make sure you get back online essentially, 'cause it's the cheapest way. get, you get your money back immediately. And it's cheaper in fees, anyways.

Yeah, awesome. And so as I understand, and this kinda gets to that idea of if you really want Bitcoin to scale non-custodially or self-custodially to as many people as possible, then having some way of scaling the number of people who are using one particular UTXO, this is like a big-- This would be a big win, right? Could you outline a little bit how you're viewing that? Like, let's say over the longer term, would this, you know, this could really improve self-custody?

Yeah. I think so. So, y-y-it improves liquidity, right? So if, if you have a channel with, with two people, right? You have two different channels with two different people, liquidity has to be spread between those two channels. But if you do a thre-three person, you know, channel, a clique between these two people and you, then all the liquidity is deployable to each direction, right? So it's a liquidity improvement. So for small numbers, I think a kind of basic multi-party setup makes sense, but if you're getting to larger numbers, you probably have to think about introducing new complexity To take care of the fact that someone will probably be offline at any given moment, right? So that's where things like, channel factories comes into play, and that That's more complexity and there's more time locks happening, so things can take longer to settle on chain. So I, I haven't really focused on that too much, but they're definitely possible.

I see. Yeah. So I guess we could think of it like it's-- there's a pathway there though, whereas if we, let's say we never get any more soft forks in Bitcoin, that will restrict the number of people who can realistically self-custody, because you have to be able to at least open a Lightning channel and have a UTXO, and I guess it's gonna be difficult UTXO set to, you know, billions of people, it's just not at all feasible, right?

Yeah, and I think that'll always be the case because you have to have a realistic threat of being able to leave the transac-- the, smart contract, right? And I think that's always gonna be-- that's gonna be very difficult. I think for large numbers of parties, I think it's a fairly unsolved problem how to make this scale. I think something like the rollup model where you have a trusted coordinator, trusted in the sense of they can make channel like- State updates unilaterally sort of, as long as they're authorized by the individual participants, and that, that allows them to batch these state updates, right? And then, but you still need this fallback period, this fallback where you as an individual can go on chain. And so this kind of, you have to have a Realistic threat of going on chain yourself at any given moment, right? And so I think that's-- there is a limiting factor, I think, to all these systems.

Yeah, that's fair to say. Because I guess, again, some of this is, it's like, there's so many moving parts, we don't know what happens, but it's quite possible that longer term, fees rise a lot, and so perhaps in an ANYPREVOUT world, in an L2 world, people can share the cost of some of those on-chain transactions because, let's say, we're in As opposed to one guy having to pay the full fee himself, right?

Yeah, and ideally you wouldn't have to go on, you'd, you wouldn't have to go on channels often because your liquidity wouldn't have to be spread out over so many channels, right? So if you can set up-- So I think the most obvious use case today would be these LSPs, lightning service providers, would connect with each other, right? So today they are connecting with each other by, you know, in a two-party manner, but maybe, you know, the, the biggest LSPs come to Together and they make a huge clique of liquidity, and that way they can reduce their liquidity requirements, which is a business con-cost, right? They're locking up liquidity for you as a customer, so they can reduce their overall costs while not redu- not reducing quality of service, because I'm just assuming these LSPs are staying online at high uptime, right?

Yeah, of course. I mean, these would be professionally managed, services, right?

Yeah, exactly right.

Yeah.

And for end users, in, in the far, far, far future, you know, maybe you do it in small amounts as end user. Or maybe we do these new constructions that allow subsets of people to be offline but new states to be signed. It's just more complexity that has to be considered.

Yeah. And so in fairness, I mean, it's not a, it's not a totally free lunch, right? There is going to be more interactivity required.

Yeah, there's always trade-offs.

So could you outline, I guess, what are some of the downsides of? Moving to the anyprevout l2 world, do you, do you see any?

Well, for l2 symmetry specifically, there's one big downside is that the, the, the timeouts for htlcs will be longer. So if you care about that a lot, that means it matters, it, it'll matter to you. there's debate about how much this matters for-- because this, this makes, essentially makes you a less, less, juicy routing node. So if you wanna be a routing node and do a lot of, do a lot of- Routing, maybe people will, will go around you because you're locking up the, you know, you're locking up liquidity for longer and it takes them a long time to get their escrows, timed out essentially. I think that's one of the biggest downsides. I think otherwise, I think all the constructions of channels that use any prevout are almost strictly superior. Like, you can pick DARC or Pick the ANTHONY Towns version or Ellen Symmetry. I think they all offer something unique and, Dark is sort of a drop-in replacement for Ellen Penalty today, in a sense. I think it's just simply better.

Yeah. And so in terms of the increased interactivity, I guess that's one other aspect, right? So let's say we wanted to move into a multi-party channel world, then you would now need your lightning node has to talk to, let's say, four other, let's say, in a five-person channel or, or whatever, right? Your, your Having to talk to them, and there's now a chance that one of them is offline at the time you're trying to sign some kind of channel state update, right? That, that would be the risk, right? Or downside.

Exactly. Today you have a channel, and the chance of it being down is the chance of you being down, forget probability. Basically, it's the chance of you being down or the other person being down, right? And so you add a third person in the mix, now it's You know, three different people that could be down, and only one of them has to be down for the channel to be inoperable, at least temporarily, right? And so basically, as you add larger and larger numbers, this probability goes up. So it's a liveliness requirement, but then you have, it lowers your liquidity requirements, and I, I think that's the key there.

Yeah, interesting. And yeah, it's just really fascinating to think about, of course, this is like kind of way off in the future, of course, the things that are just here now. If you And what, what would be the process of testing some of these things out and proving it out before there's, you know, people could build enough support for the idea of having any prevout as a soft fork?

Right. So I think with any soft fork today, we probably should have tooling already going and proving it out because this is when you really run into design constraints of these soft forks. So what I've been working on is the spec and implementation of lnsymmetry using anyprevout. I've been using my own private forks of Bitcoin Core, you know, with the necessary soft forks and mempool policies, but there is a, Anthony Towns is administering the, helping administrate the Cygnet, public Cygnet, and also doing the Bitcoin Inquisition fork, which is essentially an, an idea that you can have soft forks which are temporary on a Cygnet. And because coins aren't worth anything, it's okay if these suffixes go away or, or timeout essentially. And so on Signet, he has currently AnyPrevout activated, the current version of AnyPrevout, and also CheckTemplateVerify, another suffix idea by Jeremy Rubin. So basically, you have these soft forks already activated. So I, I could, I could basically run what I have for LN symmetry, except I have a couple of mempool requirements as, as we've been talking about. And so I'm working on getting those kind of a minimal viable, version of it. In so I can do, kind of signet testing directly of what I have implemented for core lightning. And I think that's kind of the way forward in general is making sure that, you know, if we think any prevout's good and it's good for, primarily good for like channel updates, state chains, things like that, I think really it should be proven out first, because it could be that like we go through a whole activation battle and then it ends up not being the thing we actually want, right? And so that's like a big danger, and since the cost is

Yeah, okay. And so what does proving it out look like in practice? Does that mean a big, a vibrant testnet for this or a vibrant signet for this? what, what, what would it take to really show that impact?

Yeah, I'm not sure what is Sufficient, but what is necessary for me would be, for any private specifically, it's, you know, does it actually make a, allow a new channel construction which is significantly superior to the current, current state of the art, right? It's significant benefits. So what that means? I mean, to, to me, it has, i-has meaning, but, you know, would Lightning developers in the Lightning network space be excited to implement such a thing? That's a big question to me, right? Because you could deploy a software and no one uses it. Well, that's, that's not good either, right? And so drumming up a kind of end user support or- S-layer two support, wallet support for these ideas is probably step one, right? Or step two, Brad. Step two now, whatever step we're on. 'Cause the idea sounds nice, but would people actually end up using it? That's question number two.

Yeah, and I think that was maybe one criticism that people had, or have sometimes, of soft fork ideas is they say, "Well, is there a commercial impact? Right? Are there gonna be people who are gonna-- Are there businesses who wanna build this, right?" And I think, for example, with James O'Brien's OpVault, it sounds like some of the commercial people focused on building wallets and products are excited about OpVault because it may- That's what help with securing our coins. And so, you know, I think, I think OpVault makes sense, but I, you know, I, I would love to see this idea of any prevout and like multi-party channels, 'cause I guess to me, like, it would be cool to see more people be able to self-custody than what can today, right? Because, like, it's kind of like today, there are just limits, and we can't go past them without new technology, or otherwise people end up custodial. And so, you know, we

Yeah, and I think there's iteration on what that kind of, what's the best replacement of current channels we could do today, given current knowledge, and then iterating towards that future. So, I mean, that, that's what we've been doing for the past year or so. Like, there's a lot of been, a lot has been learned in the past year, and I, I think we're gonna keep continue that

Fantastic. Well, anyw- if anyone wants to get involved, they wanna help out or they wanna, you know, learn more, what's the best place for them to go or what's, what are you looking for in terms of, involvement or help here?

Right, so there's an IRC channel, pound pound L2, that's one place if you hang out on IRC. Signet involvement, the Bitcoin Inquisition involvement, so from a developer perspective, getting reviews on that. L2, the L2 implementation itself isn't prime time. It's, it's proving out the, the protocol works, and, you know, channels can be made, payments can be made, payments can be routed, but it's not like, it's not something I would put money in, right? So it's more at the stage of kind of gathering knowledge about Getting these ideas further out there, the benefits of it for node operators, and getting feedback from both like the Lightning Network community, DLT community, state chains community, and seeing if the work that has been done already can be directly ported to these other, you know, development communities. So I, I would love to, I would love to see, for example, I'd love to see, you know, state chains using any prevout on Signet, right? The, Mercury wallet, they have a state chains based off of pre-signed transaction, like with time locks, things like Like that. It would be great to see if they could adapt their, their protocol to using any prevout and then deploying it Bitcoin Signet.

And it seems to me from most Lightning people I talk to, they are in favor of any prevout. I'm curious, what kind of feedback have you had from the Lightning community, Lightning devs, Lightning users?

I think you have a pretty, pretty solid, excitement. there's a lot of qu-people still have different opinions on like penalties and whatnot, but I think that's kind of a, now that we know that Construct kind of a fairly wide array of parameters and architectures. I think, I think that's, you know, I think we've crossed that threshold at least. So next would be getting buy-in the Elrond community, getting buy-in on kind of a specific architecture to move towards as like a, as maybe a proof of concept of, you know, interoperability, right? So it'd be great if Core Lightning and Elrond or Elrond, you know, some LDK-based one would be able to do L2 payments on Sparrow.

Yeah, okay. So, yeah, so it comes back to again that proving it out aspect. Okay, yeah, I think that's a fair point. So, yeah, I guess, is there any-- I guess outside of the any prevout and L2 and LN symmetry stuff, is there anything else that you would like to see in Bitcoin or Lightning, development or just in general? I'm curious, is there-- Are there any other things that you're interested in?

yeah, I mean, so the, the, all the tooling is pretty interesting to me. So I, Taproot support for Miniscript, I'm, I'm helping get, you know, the, all this taproot support, tapscript support, Miniscript support, all this stuff, it just takes time to build, 'cause these are s- like basically standards we're building, and we're building on top of these standards, which makes life easier going forward. I mean, I'm excited about, another, another big project I'm excited about is Fedmint and Feddy. I think that's a very interesting way forward for, you know, pluggable use Right? The privacy. So I'd say that's kind of the shorter term thing I'm most excited about is tooling and kind of this federated settlement stuff.

Fantastic. Well, I think that's probably a good spot to finish up there, Greg. Any, any closing thoughts for people

if you're interested in any of these other topics, just reach out to me. I'm on Twitter sometimes, the insta gibbs, or on IRC as insta gibbs. So love to talk to anyone about this stuff.

Fantastic. Well, thanks for joining me and, definitely a very