Payment issue with invoices from private channels when reclaiming satoshis after a failed trade

[Perlover]

Describe the bug
I've noticed a recurring issue with RoboSats over several months. When the opposite party in a trade fails to come online and the option to claim back my satoshis appears, there is a problem when providing an invoice from a wallet with private channels. Specifically, when I submit such an invoice, the payment process hangs indefinitely, and nothing happens. Upon refreshing the page, the amount of satoshis available to claim resets to zero, and the payment does not complete. I then have to reach out to the coordinator, who informs me that this issue is related to an inability to determine the correct fee for the payment.

There are two main problems:

1. If the satoshis cannot be paid, there should at least be an option to retry the payment.
2. Invoices from wallets with private channels include the base fee and ppm in the hint for the route, so fees can be calculated in advance, but the issue still persists.

To Reproduce
Steps to reproduce the behavior:

1. Engage in a trade on RoboSats.
2. Wait until the opposite party fails to show online and you are prompted to claim your satoshis.
3. Provide an invoice from a wallet with private channels.
4. Observe the issue as the payment process hangs and eventually resets upon refreshing the page.

Expected behavior
I expected the invoice to be paid successfully, even with a private channel, or at least for the system to provide an option to retry the payment if the first attempt fails.

Screenshots
N/A

Additional context
This problem has been occurring for several months, and I’ve had to contact the coordinator multiple times to resolve the issue. They’ve informed me that the issue relates to the system not being able to determine the correct fee, but the base fee and ppm are provided in the invoice hints, so this should not be a problem.

At least, this issue has frequently occurred with the coordinator Temple of Sats. It's possible that they are using an outdated version of the software, but I am not sure. However, I observe this consistently

This issue undermines users' trust in the system because, in all such cases, the satoshis cannot be reclaimed unless a public wallet is used, which exposes the recipient's node.

[KoalaSat]

Hi @Perlover , this is actually intended to avoid any possibility of exploits. An error here would allow hackers to drain the coordinator. The solution is to contact your coordinator so you can receive the payment manually.

I believe that private channels have nothing to do with the payment prpbem other than just lack of liquidity in the possible paths

[Perlover]

Honestly, I don't understand how, in this case, attackers could drain or cash out the coordinator's funds if they are receiving the funds into the private channel's wallet.

After all, the coordinator’s software is responsible for initiating the payment and determines the route independently, taking into account the hints provided in the invoice. These hints include all the fees, so the payment to a wallet with private channels shouldn’t differ from a payment to a wallet with public channels.

I can only assume that you suggest that in the case of draining the coordinator, the coordinator would be able to identify the public node of the attackers if there was no transfer to a private channel, but even in that case, it wouldn't help much.

Could you explain in more detail what the trick is here? If you were correct, then sending any payment to an invoice that routes funds to a private channel would be problematic. But in reality, that’s not the case.

[Perlover]

I believe that private channels have nothing to do with the payment prpbem other than just lack of liquidity in the possible paths

I read carefully what you wrote in the last paragraph. It seems like you agree that the private channel isn't the problem here, but in reality, I've contacted the coordinator many times, and in all cases, liquidity was never an issue. I can be sure of this because I was able to receive the same amount of reimbursement by sending it, for example, from Wallet of Satoshi or another wallet. I believe the problem lies in the coordinator’s software refusing to send or pay an invoice that contains route hints and determines that it’s an invoice for a wallet with private channels for some reason.

But the second problem, which is equally important, is that after an unsuccessful payment attempt, the balance is not restored, preventing the ability to retry the transaction.