Why is this forwarded payment failing? #8247
Replies: 3 comments
-
|
As per the thread here #7383 I attempted to do an experimental self keysend payment. Interestingly, the initial direct attempt over the actual channel I wanted to use failed. And also interestingly, the second attempt over the channel but with a hop between was successful. What? Logs: Why would it fail directly back to my node, but succeed with an extra hop between? It doesn't make sense to me. |
Beta Was this translation helpful? Give feedback.
-
|
I just had a thought here. Could this be because onchain fees are really high (full mempool) and so based on close fee estimations, that the transaction would result in not enough funds to be able to close it properly? It's just a random thought, but if it were true, it's kind of a weird situation where small channels are kind of a high risk since one of the reasons I think LN has value is that when onchain fees are high, we can use LN. But in the case of small channels, then when onchain fees are high, to the contrary, we can't use LN. I hope that isn't the case. If it is the case, then also wallets should probably just avoid trying any small channels when onchain fees are high, because they will all reject. It would be pointless to try them. I would get fewer forwarding failures at least. Again, this is assuming onchain fee estimates is the cause of the problem here. |
Beta Was this translation helpful? Give feedback.
-
|
I found a line like this in the logs: So yeah, it looks like it's because the fees on-chain are high at the moment. I think this means it's important to have bigger channels and well balanced channels so they don't run into this forced reduced local balance. Since the majority of the balance is on my side of the channel, they can't send sats to me, and I can't send sats to them, so it's an effectively dead channel. |
Beta Was this translation helpful? Give feedback.
-
I'm trying to figure out why this forwarded payment has failed.
Running
"version": "0.17.0-beta commit=v0.17.0-beta",.It looks like from the logs that I didn't have sufficient local balance on my channel. But actually, I think I do? The local balance is 493,091. Even if we take some reserve sats into consideration, it should be enough for a 123,153 sat forward, no?
Some calculations to be noted...
123153195 mSAT = 123,153 sats
353999 mSAT = 354 sats
The channel
756344:1059:1is the same asaa5d250d6ea3b4928ba6a16fd0daea8261b997edecace50801270cbe25710b18.The only place I see a mention of
354 satsis found in thedust_limit_satbelow:Doesn't the dust limit mean something like if the transaction is too SMALL, then it should fail? In this case, the transaction is larger than the dust, which is a good thing, isn't it?
123153195 mSAT is larger than 353999 mSATDon't we want it to be larger?
Also, just to be sure, the incoming channel for the forwarded payment is very large and has more than 3m sats both incoming and outgoing available so that definitely shouldn't be a limitation.
Why did the forward fail with such an insufficient bandwidth message if there seemingly is sufficient local balance on the outgoing channel?
Beta Was this translation helpful? Give feedback.
All reactions