-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Charge channel opening fee through lsp flow #1528
Conversation
e310274
to
c684b7d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, looking forward to having this in production :)
format!("Couldn't find channel for user_channel_id {user_channel_id}",) | ||
})?; | ||
|
||
if channel.channel_state == ChannelState::Open { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓
I don't understand, why would you fail if the channel is already open?
Wouldn't that prevent you from receiving payments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because then it is already been paid for.
ChannelReady -> OpenUnpaid
PaymentClaimable -> Open
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't understand: isn't the event PaymentClaimable
called for all payments? Meaning, even after the channel was opened paid successfully, if the user tries to receive something, we would fail here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only if counterparty_skimmed_fee_msat > 0
, or in other words only if the counterparty is skimming fees from the payment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this scenario means that the coordinator is trying to take extra fees from random payments after the JIT channel has already been created and the opening fee has been paid.
So the app should reject any payment that is taking extra fees arbitrarily. Perhaps eventually it would make sense to show this to the user, so that they can decide whether they want to pay for the special fee or not.
You might want to top getting some of the fixes in separate PRs straight into |
c684b7d
to
82a712f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
coordinator/migrations/2023-10-25-120015_add_fee_to_channel/down.sql
Outdated
Show resolved
Hide resolved
/// If the payment was used to open an inbound channel, this tx id refers the funding | ||
/// transaction for opening the channel. | ||
pub funding_txid: Option<Txid>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙃 Perhaps not worth it here, but it's nice to think about ways to avoid optional fields.
For instance, we could extend the PaymentFlow
enum to something like:
enum PaymentType {
Inbound,
Outbound,
Funding {
funding_txid: Txid,
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
opted to not do the change as it became too big of a change very quickly :/
@@ -33,10 +33,12 @@ async fn ln_collab_close() { | |||
.await | |||
.unwrap(); | |||
|
|||
let fee_sats = 10_000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔧 Should this not come from the liquidity options or something like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically you are right, but on these tests we do not know about the liquidity options. This is only known on the application layer of the coordinator and the app. I am using a little hack to inject the fees in the liquidity request, but for that I have to do it manually.
mobile/native/migrations/2023-10-25-120015_add_fee_to_channel/down.sql
Outdated
Show resolved
Hide resolved
aa6fe70
to
32a9226
Compare
9d0c54b
to
2e19e87
Compare
32a9226
to
8ef9415
Compare
2e19e87
to
dd8812b
Compare
8ef9415
to
247a892
Compare
dd8812b
to
82d89a3
Compare
IF EXISTS does not exist on sql lite. I stumbled upon that issue when trying to rerun all sql migration scripts on the app.
82d89a3
to
f71d546
Compare
This change was fairly simple with the new channel config flag
accept_underpaying_htlcs
🎉. The main change is in this commit abb2febresolves #843
fixes #1147
fixes #1366
fixes #1445
Simulator.Screen.Recording.-.iPhone.14.Pro.-.2023-10-26.at.08.48.12.mp4
Unrelated minor fixes that could get separated into a single PRs.