Support 0 counterparty channel reserve

[moneyball]

see discussion here: https://discord.com/channels/915026692102316113/915026887066132481/1034521052849639555

[TheBlueMatt]

This is relatively unsafe. Its something we could be open to with specific user demand, but for now we haven't seen any, so I don't think it makes sense.

[G8XSU]

Hi Steve,
Can you add some additional context/reasoning here?

There is no safe way to do this.

Allowing for 0 is also against current BOLT specification IIUC, which says that there should be lower bound of atleast dust_limit_satoshis on channel reserve.

Acc. to current impl as per #1619 , there is an implementation-specific lower bound of 1000 sats on this.

[moneyball]

tl;dr Phoenix does this, so it could not be built by LDK today

Context/reasoning:
"the use case is so a user can spend their entire wallet. phoenix supports this. so phoenix could not be built with LDK right now."

"ok but the benefit is quite clear, yes? it improves the UX because users assume they should be able to spend their entire balance. it also avoids needing to communicate what a reserve is and why it is important "so that you, the user, do not steal from your service provider.""

Regarding breaking BOLT spec, I'd be curious to get Bastien's take on this since Phoenix/Eclair are doing this.

As for security, I'll copy more of the discussion from discord here:
Steve: "can we walk through the security concerns in more detail to make sure we're clear on those? so i understand a user could spend their entire balance so has 0 sats on their side of the channel ... and now they could publish an old state trying to steal sats, and their punishment is ... none because the LSP punishing them by taking the entire value of the channel is already all of the LSP's money. right?

but perhaps this is worth the risk for the LSP in order to create a better wallet UX because the LSP is likely in a position to have high-uptime internet connectivity, robust against eclipse attacks, relatively robust against fee attacks, etc.

am i missing additional security concerns? or how this could play out badly for LSPs?"
...
"still don't quite understand this. for most users, they won't try to do this simply because they do not have the awareness or ability or time to do so. for a smaller set of users, they won't do this because they know or will learn that it is unsuccessful because the LSP won't lose money as they'll "punish" them. And those users won't want their channels closed. So we're really just talking about sophisticated attackers who would try to target the LSP and eclipse attack or some other advanced attack, right? And if the LSP can be eclipsed there are all kinds of other problems they face?"

Matt: "i mean if there's no punishment at all all kinds of things become free - because the LSP opened the channel all fees are paid by the LSP, so the user can broadcast an old state without even paying any fees. i wouldnt call it an "advanced attack" to do "the fees in the mempool increased"-based pinning?"

Tony: ""Free" is assuming the LSP is also routing payments for free too which shouldn't be the case in practice. An LSP removing reserve requirements should be assumed to being capable of being online and also running watch towers.
LND has even allowed the configuration of removing reserve requirements, despite years of pushing back against Breez wanting this"

Antoine: "Don't seem new to new to me, if you have a 0 channel reserve that the cost of a lot of attacks become opportunity cost free for LSP spokes
In practice, LSP might have additional layer of users reputation enforcement. Like allow 0 channel reserve if you've previsously opened a channel with age X blocks/days/weeks."

Matt: "sure, you had to have paid a fee to route some payment so its not free in that sense, but the attack itself has zero opportunity cost.

but part of my point is that you can do simple attacks that probably work quite well today
eg if fees go up and there's a backlog, just broadcasting a commitment tx and waiting is a pretty likely-to-work attack
that's more of an anchors issue than an issue here
but the fact that there's suddenly zero opportunity cost to try is kinda...shitty?"

Tony: "But is the attacker going to make any money from that against a sophisticated LSP? When they are paying routing fees? Sure, they can make that action but are they going to repeat it with the intent of trying to take money?
Well, I guess in some cases only the payer is paying the fees"

Matt: "if the commitment tx confirmation is delayed by a day, yes, you can steal funds
which is really a shortcoming of anchors as implemented broadly today/bitcoin core
but at least trying it in a "traditional" world has an opportunity cost
where the mempool backlog could clear and you could lose funds"

Antoine: "In case of sufficient mempool backlog, the pre-signed feerate of your commitment transaction might be under the backlog bottom, and the backlog has a block-sized enough to swallow the timelocks"

Tony: "Not that I'm advocating for making it easier to attack LN, but if in the end there's this consensus that it is unsafe to open channels with people you don't know whether we have reserve/justice or not, I feel like an LSP running a business will be charging the fees to make up for the risk. And if they are always online anyways and there's no sudden chain fee rise, I don't see them losing any more money than everyone is vullnerable to anyways.
Just trying to differentiate the risks all LN users have and the risks an LSP has if they are doing 0 reserve requirements for their users."

Matt: "yea, I mean I dont think the risks themselves are different, its just a question of "if you try to attack and fail you lose money" vs "zero cost at all", and given almost all the attacks in lightnign are "this will probably work, but in theory if they notice and take manual intervention the attack wont work""

[TheBlueMatt]

Just to be clear here - some LSPs allow the user to have zero reserve, but do not themselves take zero reserve. The client side is doable in LDK, it's the LSP-end that is not.

In any case, we'll want to make sure we can't fall into the traps described in lightning/bolts#959 for this.