Understood this part, using HTLCs is a brilliant idea. Just can't figure out this one edge case in my head:
Now Bob is able to retrieve the X BTC using the secret R. And as soon as he does, the secret will become available to Alice as well.
What if Bob doesn't share the secret right away, but waits until Alice's channel with me expires (our channel with him is set up for a longer period of time), I take away all the funds in the channel with Alice (she can't do anything, because she doesn't know
R), and then Bob publishes tx with
R when it's too late for her but not too late for him, thus he also takes away funds from Alice in his channel? We've successfully defrauded Alice, haven't we?
Alice can easily circumvent being defrauded by choosing a timelock (between Alice and Bob) < timelock between You and Alice.
As i have mentioned in my example:
Then, based on this you are going to create a HTLC with a timelock. This basically says 'I (you) pay X btc to Alice if she finds the secret R during the next Y blocks. If not, the funds return to me'.
Afterwards Alice (using the same hash) creates a HTLC with Bob where she pays Bob X (- fee) btc. The HTLC basically says 'I (Alice) pay X btc to Bob if he finds the secret R during the next Y-1 blocks. If not, the funds return to me'.
Your approach of defrauding alice would not have worked here.
Since we are talking about bi-directional channels, the locktime is going to be decreased each 'hop'.
Edit:
Hopefully, this is already included in the emerging LN standards.
From the whitepaper of the LN (source:
https://lightning.network/lightning-network-paper.pdf):
8.
By having a micropayment channel with contracts encumbered by hashlocks and timelocks, it is possible to clear transactions over a multi-hop payment network using a series of decrementing timelocks without additional central clearinghouses.