Can we prove solvency with HTLC on Lightning?

So, as most of you probably know, the Lightning Network operates differently than the Bitcoin blockchain there's no "global state" to check, since it's more private. That means you can’t just look up the balance of a Bitcoin address like you could with a block explorer on the blockchain. However, it might be possible to set up a transaction between two parties, let’s call them A and B, where A can show B that they have X amount of BTC without either needing to trust the other. The idea is to implement an HTLC between them. A sends an exact amount X to B, but then B has to send that same amount X back to A using the same secret (preimage) and hash. If the transaction goes through, A has essentially shown B that they have access to a specific balance. I found this paper discussing something similar, and the method I'm talking about might relate to what they call "payment probing" (but it doesn’t go into detail). I do have some questions though: 1. Would the HTLC(s) need to be tied together with more than just the preimage/secret? Like, what happens if B doesn’t have enough funds to complete the transaction? Wouldn’t A just send X and then B wouldn’t send it back? Or if it was the other way around (B sending X first with quicker timing), then could A potentially scam B? 2. Is this kind of "fake swap" something the Lightning protocol can handle? No actual funds would be exchanged, except for fees. If there’s a specific name for this technique, I’d love to know.

Your idea about using Hash Time-Locked contracts(HTLC) for the proof of solvency is interesting.. Not sure about exploiting the system, but to ensure that both  A and B  fulfill their part, you could implement a system to bind the transactions together by  using multi signatures contracts where both A and B sign off the transaction and then they both will need each others consent to complete the transaction.   Also to prevent scams maybe the system having a timeout mechanism might help, I.e if the conditions aren’t fully met with a certain time, then the funds should be returned to its original owner(s).

You’re thinking in the right direction but Lightning kind of pushes back on this by design. I might be missing something but the shared preimage doesn’t bind the two payments strongly enough. If A sends first, B might not return X and if B sends first, A can just claim it. There’s no native way in LN to make both sides succeed or fail together. Even if no one really loses money, these are still real payments, liquidity gets locked, routes are touched and fees happen. From the network’s point of view, that actually matters. That’s why this feels closer to payment probing than an actual solvency proof. Basically, Lightning isn’t built to make balance attestations easy.

At a first glance I thought, multisig looks good, even if the implementation would probably need protocol upgrades. But then I thought a bit more and I remembered why this probably does not help here: Lightning works because of its potential to threaten you to punish you emptying your whole channel. But the problem is that in the attack I have in mind, the verifier (B) would not even have balance at the channel. Or have enough balance initially but then instantly, before A sends their funds, transfer the funds away. This means that A would try to close the channel to punish B, but the transaction would not go through, because the output referenced in the penalty transaction would no longer be unspent. On the other hand, this problem must have dealt with in all Lightning-based atomic swaps too, e.g. if you do an atomic swap between Ligthning-BTC and Lightning-LTC, and these atomic swaps seem to work, so there must be a solution in my opinion. Probably a chain of transactions like in the "on-chain" variant of atomic swaps can do it. Maybe I have only a knot in my brain and Lightning HTLCs already are constructed in a way that this kind of attack isn't possible (although this techique would be something like a "second layer HTLC based on first-layer HTLCs"). I have found the following paper on "payment probing" from 2020: https://arxiv.org/abs/2004.00333 Approximately their technique is this way: - You consult the gossip data of LN (the data you would consult to route a payment) to see if the channel you want to check is open/active. - You connect to both of the nodes of the channel via P2P connection - You send a payment through this channel. I haven't understand the paper completely how you avoid to lose funds here, I assume that you pay to another node under your own control. This means that in our example with Alice (A) who wants to prove she owns X and a verifier Bob (B), Alice could prove her balance in the following way: - Bob connects to Alice and her channel partner, - then he sends a payment of X from one of his nodes, B1, to another node B2, routing through Alice's channel, - if the payment goes through, then he has proven that Alice has the payment capacity X. The paper arguments however that the technique described exploits a vulnerability, because everybody can act like Bob and "probe" channels, and its possible that newer Lightning versions are already "fixed" and this is not longer possible. In addition Alice needs two nodes in this concept. The technique I described in the OP, instead, would not be a vulnerability because it would only work in agreement between "prover" and "verifier" and would not prove the balance, but only a determined amount chosen by the "prover". As long as both have enough balance on their channel the exchange should work because if one party doesn't fullfill their duty the other one can just close its own channel with the penalty transaction sighed by both, so this particular attack should not be possible.

I see it a bit different. Lightning depends on that you can always check if a route works, and thus there needs to be a way to check if all nodes on that routes have enough balance for the payment. And this mechanism can be used if you know not only the address of a Lightning participant, but also the node identity. So if a Lightning user is willing to trust a verifier to check its balance (and that's all what I'm searching for in this case) then that verifier shoud be able to do a payment probe through their channel. It's not very different from a "proof of solvency" in on-chain Bitcoin, where the verifier also needs the connection between identity and address(es) to check the solvency of a person. (That requires of course that this user is connected to LN via two different channels at least.) I haven't understood this sentence, can you elaborate? Of course if a node from/to the route on one side has no liquidity, then the proof will fail, but then the person wanting to prove their solvency would also not be able to make a payment through this route and thus not be "solvent". If that was a problem, it would have a relatively easy fix: the verifier could re-send the amount through the nodes "the other way around" and thus re-establish the balance and liquidity of both. However, there seem to be probing techniques where the payment fails deliberately due to a timeout and actually no coins really move. I still have to search more info about these techniques because these would be the best way. Again here: If this would not work at all then Lightning could not even route payments correctly. Edit: I think @Hodlpreneur's posts did add some aspects like the pressure in between, so I'm not sure if it was correct to delete it (however I honestly have no idea if this user was AI spamming).