So...How are We Activating Eltoo (LNSymmetry)? \ stacker news ~bitcoin

pull down to refresh

So...How are We Activating Eltoo (LNSymmetry)?

5526 sats \ 12 comments \ @nerd2ninja 17 Jan bitcoin

About a week ago, Darthcoin made a post using the nostr protocol about how while channel opening fees are manageable in the lightning network, unexpected channel closing fees in high fee environments are unacceptable and unmanageable.

You can see that post here: https://primal.net/e/note10rprgyaltjyumf42079x2pq7zv0g9jlxdjrzuhetm689t08jvzlsssfgn5

So how do you remedy this issue? One solution presented to get all the different implementations for LN to agree on rules that are more forgiving about downtime and stuck payments and don't go straight to force closures so quickly.

Another method is LNSymmetry (formerly known as eltoo). It does away with the justice transaction and allows for any later state to replace any older state. So if you close a channel with a low fee, you don't have to sweet bullets over your peer trying to submit an older state to cheat funds out of you with a higher fee, because you can just replace their older state with the newer one.

APO is one of those BIPs that everyone seems to like...but no movement at all seems to be made to activate it. I posted information about APO on reddit once and 1 commenter (the only commenter) asked why it wasn't activated yet. You should know, that APO discussion became complicated because people figured out you can do covenants with it.

"(APO) can also be used to emulate a CTV-like covenant and all its use-cases, but this emulation is both more fragile (as you need to store signatures and pre-signed transactions) and less efficient, so it is not an ideal solution to bring about these use-cases." -https://covenants.info/proposals/apo/

More APO information: https://anyprevout.xyz/

Another method for activating LNSymmetry (and covenants) is CTV + CSFS (CTV can not do covenants by itself). Of the 2 activation clients written for CTV (I again remind you that no activation client has been written for APO), only 1 contains CSFS. Its actually 3 BIPs. The third BIP is very simple tho. It just makes referencing taproot keys from the stack possible so that you don't have to write out the whole key over and over again, thereby saving space.

https://cdn.discordapp.com/attachments/796935699034144798/1196271271764304005/jpegdim500x544blurhashNJa_19uVxVksngt7Imgs9DXAs.jpg?ex=65b70570&is=65a49070&hm=ee56c51b667b81d5897cb0208b2a98159875d9b257d8dea31bae94625c87a5d9&

Unlike CTV + CSFS, I have seen an LN client written for APO that implements LNSymmetry. You can test it out here: https://github.com/instagibbs/lightning/tree/eltoo_support

So APO has no activation client to rally around, but a test application people can try. Meanwhile, while CTV advocates a very good about posting code blocks, I personally run into trouble finding the test apps they've made.

An Eltoo codeblock written by moonsettler for LNHance: https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/8

CTV advocates did write a test app for vaults, but quite frankly, people don't care enough about vaults to get anyone up in the morning to talk about activation among peers. Nontheless, I do like the LNHance BIPs. I could go on and on about timeout trees and flow control and all the rest, but I'm here looking for consensus among my node running peers, not to preach about a BIP being better than the other.

I've seen "Lets do APO" I've seen "Lets do CTV then APO" and I've seen "Lets do CTV + CSFS" and of course I've seen "What about more general covenant BIPs" honey we're trying to get consensus over here nobody is even discussing TXHash right now in any context other than to interject with "but what about it"

We really are in a spot where Eltoo/LNSymmetry discussion is also a covenants discussion. I will fall in line with what ultimately gets decided for with which BIP we want to use to get this thing, I'm only here to ask you how we're going to do it.

view all related items

1646 sats \ 7 replies \ @petertodd 17 Jan

The problem with Eltoo is that removing punishment has serious risks in untrusted environments. Your counterparty can steal a lot of money if they manage to get a revoked state mined, up to almost the entire balance of the channel.

With Eltoo, the only disincentive to attempting a theft is transaction fees. Which, if you want to close a channel anyway, isn't necessarily much of a disincentive. The attempt might not succeed. But even a 5% chance of stealing a lot of money can make it worth it if there is no downside to trying.

Eltoo is probably ok for more trusted environments, eg between parties that know each other, where an attempt at theft can be discouraged with out of band punishment. But the fact that it has this massive potential problem in the quite common case of untrusted channels has discouraged interest into it.

Incidentally, there are other use-cases for APO too. I personally have proposed them for HTLC transactions to make RBF work better: https://petertodd.org/2023/v3-transactions-review#htlcs-and-replace-by-fee

But not a lot of work has been done examining those use cases in detail.

142 sats \ 0 replies \ @netstatic 17 Jan

Even if the penalty is reduced for broadcasting an old state, it shouldn't matter if both parties have a watchtower. In the case of a broken/non-functional watchtower the loss of a lot of money would happen in both lightning and eltoo.

I agree that the decreased risk would probably result in more old states being broadcast, but maybe it's a good thing for a watchtower to be tested more frequently. It should also be easier to manage watchtower software in eltoo since only the latest state is needed so I wouldn't be surprised if lighter weight supplemental watch tower services started to rise up.

94 sats \ 3 replies \ @nerd2ninja OP 17 Jan

So this is the first time I've ever seen anyone have a concern with LNSymmetry so this is exciting lol.

After I read your comment, I had this thought that I was kinda holding back, but I'll go ahead and put it out there now.

The idea behind using LNSymmetry is to then have multi-party channels. So, broadcasting an old state doesn't screw over 1 person, but rather maybe 10 or more people and those other people have a vested interest to also ensure that the newest state is the one that gets mined so even if 1 person is having some node trouble or temporary internet connectivity issues, those other people can jump in and save them not out of altruism, but to save themselves.

Now of course a multi-party channel of 10 people could contain only 2 unique individuals, and maybe that gives rise to LN node IDs being used as pseudonyms, and that does introduce a degree of trust into the system.

So I don't have much else to say other than "huh, that's interesting".

121 sats \ 2 replies \ @petertodd 17 Jan

The idea behind using LNSymmetry is to then have multi-party channels.

Yes, that's a more advanced version of the idea. But multi-party channels have their own problems, in particular, coordination. It's very difficult to get more than a few parties coordinated.

Which again, has limited enthusiasm for Eltoo.

0 sats \ 1 reply \ @nerd2ninja OP 17 Jan

The first thought that would come to mind is like a mempool for multi-party channels.

So for example we have this transaction batching service https://peachbitcoin.com/blog/group-hug/

So you would just modify that to return a multi-party channel rather than outputs to all these different addresses.

Now that doesn't work if the architecture incentivizes using nodeIDs as pseudonyms. So in that case they might coordinate on amboss.space or maybe they would coordinate over here; https://lightningnetwork.plus/ because these style of channel opens already look very similar to the coordination you need for channel factories.

Maybe channel factories work a bit like a video game guild where you send a message requesting to join and the participants of the channel factory do something similar to a channel splice to get you added in

Still though, I'm gonna go reread some whitepapers specifically how they handle the uncoorperative close mechanism.

0 sats \ 0 replies \ @ZezzebbulTheMysterious 18 Jan

I really like https://lightningnetwork.plus/ and have used it to bootstrap liquidity for one of my nodes. Folks should take a look if they have not seen it.

I look forward to when we can use such a pseudo social-network for channel factories and multi-party channel coordination.

31 sats \ 1 reply \ @endothermicdev 17 Jan

This game theory sounds reasonable enough. @theinstagibbs will point out that in reality, an attacker can still attempt to cheat without much at stake on ln-penalty by draining their balance in advance. There's basically the same downside for a motivated attacker in either case, but at least under ln-symmetry the node runner who lost state isn't unnecessarily punished, which currently seems to occur far more often.

I'm sympathetic to your argument of "messing with the game theory may increase the likelihood of cheating attempts," but I think the rebuttal is quite reasonable too.

1000 sats \ 0 replies \ @petertodd 17 Jan

@theinstagibbs will point out that in reality, an attacker can still attempt to cheat without much at stake on ln-penalty by draining their balance in advance.

That's why Lightning channels have a channel reserve. You can't drain your entire balance.

50 sats \ 0 replies \ @ZezzebbulTheMysterious 18 Jan

I 100% agree with Darth here. Force closes are killing my enthusiasm for node running. It is totally out of your control if the HTLC timeout event occurs, and you accept liability up to the on-chain balance of your node to fix in emergency channel closes at excessive fees. It was never profitable, but now you risk funds to forces outside your control.

We need to fix this.

0 sats \ 0 replies \ @1440000bytes 17 Jan

Please join this twitter space in a couple of hours hosted by reardencode to discuss everything related to covenant proposals: https://x.com/i/spaces/1vOxwjDqEaEJB