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.
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".
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.
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.
