Enable 0conf and 0reserve on channels with trusted peers#853
Enable 0conf and 0reserve on channels with trusted peers#853tankyleo wants to merge 1 commit intolightningdevkit:mainfrom
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
|
| prost = { version = "0.11.6", default-features = false} | ||
| #bitcoin-payment-instructions = { version = "0.6" } | ||
| bitcoin-payment-instructions = { git = "https://github.com/joostjager/bitcoin-payment-instructions", branch = "ldk-dcf0c203e166da2348bef12b2e5eff4a250cdec7" } | ||
| bitcoin-payment-instructions = { git = "https://github.com/tankyleo/bitcoin-payment-instructions", branch = "ldk-688544da72cb348e4405d39a75e4d81102c1278a" } |
There was a problem hiding this comment.
Should we use rev here? Seems otherwise the revision could move if the branch is updated.
| /// | ||
| /// **Note:** Allowing payments via zero-confirmation channels is potentially insecure if | ||
| /// the funding transaction never gets confirmed on-chain. Zero-reserve channels | ||
| /// allow the counterparty to make cheating attempts with no financial penalty. |
There was a problem hiding this comment.
| /// allow the counterparty to make cheating attempts with no financial penalty. | |
| /// allow the counterparty to attempt cheating with no financial penalty. |
| /// funding transaction ends up never being confirmed on-chain. Zero-confirmation channels | ||
| /// should therefore only be accepted from trusted peers. | ||
| pub trusted_peers_0conf: Vec<PublicKey>, | ||
| /// A list of peers that we trust. If a peer on this list opens a channel to us, we will |
There was a problem hiding this comment.
nit: Please expand the first sentence slightly and give it its own paragraph.
| }, | ||
| let is_trusted_peer = self.config.trusted_peers_0conf_0reserve.contains(&node_id); | ||
| if is_trusted_peer { | ||
| match self.channel_manager.create_channel_to_trusted_peer_0reserve( |
There was a problem hiding this comment.
Hmm, I'm a bit dubious if we indeed should always opt for 0reserve if the peer is marked trusted?
| /// allow them to spend their entire balance (zero-reserve). If we open a channel to a peer | ||
| /// on this list, we will allow them to spend their entire channel balance (note that for | ||
| /// channels *we* open, the decision of whether to accept HTLC forwards with no | ||
| /// confirmations of the funding transaction is *the peer's* decision). |
There was a problem hiding this comment.
Hmm, to be honest this is what makes it a bit weird to mix the concepts: yes, both require trust in the counterparty, but the AFAIU the use case is entirely opposite:
- We usually opt into 0conf if we are the client and want to allow the LSP to open 0conf channels
- If we are the client, there is little incentive to allow the LSP to not keep any reserve? So setting 0 reserve only makes sense if we are the LSP and want to allow the client to spend their full channel funds, no?
So, rather than also setting 0reserve if we are a LSPS client (see above), shouldn't we only set that if we are the LSP? Or maybe I'm missing something?
There was a problem hiding this comment.
If we are the client, there is little incentive to allow the LSP to not keep any reserve? So setting 0 reserve only makes sense if we are the LSP and want to allow the client to spend their full channel funds, no?
Thanks for the review will mull on this more, a quick reaction to this point: the LSP might want 0-reserve on their side of the channel for greater capital efficiency, ie dedicate as much of their capital as possible towards allowing clients to receive payments. If they get caught making even a single cheating attempt, their entire reputation is burned, and their business goes to 0 (hopefully !) so the incentives are aligned. 1000sats (the min reserve) * x users quickly becomes a lot of dead capital.
So, rather than also setting 0reserve if we are a LSPS client (see above), shouldn't we only set that if we are the LSP? Or maybe I'm missing something?
I see your point yes. Do you have in mind to not offer any public API for setting 0-reserve on outbound channels (assuming the client is usually the opener of the channel, and not the LSP) ?
If we were to offer a completely separate API we have these options:
- Standalone function calls; this would at least require two more
open_channelfunctions, one with max funding, and one with a parameterized amount. - A separate list, similar to what we currently have for inbound channels.
- Some kind of boolean / enum flag on the existing
open_channelfunctions.
4 participants
No description provided.