Suppose there exist two such payment transfer request: A transfers 1 msat to R via A->B->C->R and S transfers 5 msat to R via S->B->C->R. Let the two HTLCs be formed across both the paths simultaneously and let both the payment use the same payment hash say H. Now channels B-C and CR has two HTLC using the same payment hash. As mentioned in https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages it is stated that "An intermediate hop MUST NOT, but the final node: if the payment hash has already been paid: MAY treat the payment hash as unknown or MAY succeed in accepting the HTLC." It seems that R can release the preimage of H and settle both the payment if R has received both the HTLC request at the same time. However, is it so that R will settle one payment and fail the other so as not to encourage the reuse of hash?
1 Answer
R cannot fail the payment once they have released the preimage. The commitment transactions which were agreed before R released the preimage contain a condition where the payment_hash is embedded in the script. By providing the preimage as part of the witness to this script, each party can claim the amounts due to them without cooperating with the other party.
In the case of C forwarding a payment from B to R, C will agree their commitment transaction with B before they negotiate their commitment transaction with R, and so forth.
The commitment transactions are only invalidated when a new state is agreed where the relevant HTLCs have been removed, which no party will agree to unless they have received the corresponding preimage or had the HTLC removed by the party they are forwarding payment to.
R doesn't need to try and invalide a transaction to not encourage reuse of a payment_hash, because R creates the payment_hash to begin with. If he uses a proper DPRNG, the chance of two payment_hash colliding are unimaginably small.
Intermediate nodes are not required to keep track of the preimages which have previously been used, and it would be unreasonable to expect them to. Most of the time, they will just forward the payment because they have nothing to lose by doing so - the party who sends them the money commits to the funds before this intermediate party commits to forwarding them.
It is possible that a node keeping track of previously used preimages could steal funds if they see one reused. They could use their knowledge of the preimage to remove a HTLC and receive the money from the sender, but not forward anything on to the remaining nodes in the path.
If a node such as B or C does keep track of previous preimages, and R fails a second payment using the same payment_hash, then B or C could decide not to forward this failure on to the sender of funds, and instead claim the money by fulfilling the HTLC or broadcasting the commitment transaction agreed with the sender.
