Quote from: BitCryptex on August 16, 2018, 10:48:41 AM

That's why Hashed Timelock Contracts are used in the payment channels.

Quote

Example

   Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
   Alice wants to buy something from Charlie for 1000 satoshis.
   Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
   Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
   Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
   Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
   Bob uses the pre-image to finalize his payment from Alice

Oh, that's smart, I get it now. And I've read bob123's link, same thing. Thank you folks, just what I needed.

Now the only concern is that if Alice-Bob channel expires earlier than Bob-Charlie's, Charlie can maliciously withhold the preimage until A-B channel expires (and Bob can't take Alice's funds, because he can't provide the correct preimage to form the unlocking script, and Alice takes them all because the timelock expired), while Charlie publishes the preimage in time after that to grab Bob's payment; but that 1) requires conspiracy between Alice and Charlie, and 2) we can probably check this condition somehow, by requiring access to and validating all channels in the chain.

Upd: Actually, can we do 2)? I know we're deep into the woods at this point, but I would appreciate if anybody shares their ideas on how this attack can be mitigated.