-
Notifications
You must be signed in to change notification settings - Fork 40
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
probe payment as sanity check #260
Conversation
Change MinSwapAmountMsat to be set by policy.
Added test case to confirm that swap fails on StuckChannels. Allow pushAmt to be set during setup. Set min_swap_amount_msat to 1.
Replace sanity check with probe payment in SpendableMsat. ProbePayment trying to pay via a route with a random payment hash that the receiver doesn't have the preimage of. The receiver node aren't able to settle the payment. When the probe is successful, the receiver will return a incorrect_or_unknown_payment_details error to the sender. If the result of ProbePayment is assumed to be a payment failure, log the reason as known by ProbePayment
138a0dc
to
e5cbb6b
Compare
Asking for opinions @nepet. I think removing the previous sanity check isn't ideal. The existing balance checking current sanity check can tell us for sure that a probe would fail. The cost isn't high to probe but it is not costless. The current sanity check prevents a tiny bit of database bloat in situations where it is guaranteed to fail. Probing seems to be the correct check after the costless sanity check. That is worthwhile to do at this step as it that prevents on-chain fee wasting. |
Route may not be built even when channel is active. Since this causes flaky test, Added to check route construction in advance.
969bf95
to
5d79e9e
Compare
Restored sanity check of the maximum htlc limit. * To check max htlc more strictly than CLN's own limits. * To prevents a tiny bit of database bloat in situations where it is guaranteed to fail.
cd42ebd
to
dbec5bb
Compare
I restored sanity check of the |
On Liquid testnet I tried L-BTC swaps: CLN swap-out initiator:
LND swap-out initiator:
I will add another comment with mainnet test results. |
On mainnet the probing / checks in this PR seem to still allow impossible swaps to occur when using a stuck channel:
More info:
|
#260 (comment)
Probe occurs twice, which is the expected behavior. |
#260 (comment) |
I think it is possible that the stuck channel may have been caused by the payment of the fee invoice. If you could share the results of the |
What does the second probe gain us? If I understand it correctly no harm is done if the payment fails? The preimage is not revealed. It can still fallback to Coop Close to CSV after timeout? |
When we receive the
If payment to |
OHHH I read the description wrong. This sounds correct. I would strongly prefer that @nepet reviews this though. |
require := require.New(t) | ||
// repro by using the push_msat in the open_channel. | ||
// Assumption that feperkw is 253perkw in reg test. | ||
bitcoind, lightningds, scid := clnclnSetupWithConfig(t, 3794, 3573, []string{ |
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.
Numbers checked. They match 1% reserve 37940 msat and a CommitTx fee of 183172 msat.
This gives the funder 221112 msat for a stuck channel. The configuration leaves 221 sat on the funders side which results in a stuck channel.
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.
This looks pretty solid! Good work! I am just confused about the way you construct the route (see below).
clightning/clightning.go
Outdated
} | ||
} | ||
|
||
route, err := cl.glightning.GetRoute(channel.PeerId, amountMsat, 1, 0, cl.nodeId, 0, nil, 1) |
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 fail to see the reason in choosing a route that core lightning constructs for us? Should we not construct the route that uses the exact channel for probing that we also use for 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.
Yes, I agree with your suggestion.
Like PayInvoiceViaChannel
, I have modified to ensure that invoice payments are probed through a direct channel to peers.
clightning/clightning.go
Outdated
if !ok { | ||
return false, "", fmt.Errorf("WaitSendPay() %w", err) | ||
} | ||
faiCodeWireIncorrectOrUnknownPaymentDetails := 203 |
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.
nit: typo failCodeWire...
474f260
to
0b59602
Compare
To ensures that the invoice payment is probed via the direct channel to the peer.
0b59602
to
52e2ff3
Compare
Corrected the parts that were reviewed. |
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.
Thanks a lot!
Ack 52e2ff3
What
I added sanity check of
ProbePayment
.If the result of
ProbePayment
is assumed to be a payment failure, log the reason.Also, change
MinSwapAmountMsat
to be able to set by policy to test stuck channels in test.Why
LN channels can get stuck in rare.
The onchain fees were wasted because they could not be detected.
By probing payment, sanity checks can detect them.