itest: update multi hop test case docs

To make clear whcih sweep scenarios are actually being tested

lntest/itest/lnd_multi-hop_htlc_local_chain_claim_test.go

@@ -18,9 +18,9 @@ import (
 )
 
 // testMultiHopHtlcLocalChainClaim tests that in a multi-hop HTLC scenario, if
-// we're forced to go to chain with an incoming HTLC, then when we find out the
-// preimage via the witness beacon, we properly settle the HTLC on-chain in
-// order to ensure we don't lose any funds.
+// we force close a channel with an incoming HTLC, and later find out the
+// preimage via the witness beacon, we properly settle the HTLC on-chain using
+// the HTLC success transaction in order to ensure we don't lose any funds.
 func testMultiHopHtlcLocalChainClaim(net *lntest.NetworkHarness, t *harnessTest) {
 	ctxb := context.Background()
 

lntest/itest/lnd_multi-hop_htlc_local_timeout_test.go

@@ -18,9 +18,9 @@ import (
 
 // testMultiHopHtlcLocalTimeout tests that in a multi-hop HTLC scenario, if the
 // outgoing HTLC is about to time out, then we'll go to chain in order to claim
-// it. Any dust HTLC's should be immediately canceled backwards. Once the
-// timeout has been reached, then we should sweep it on-chain, and cancel the
-// HTLC backwards.
+// it using the HTLC timeout transaction. Any dust HTLC's should be immediately
+// canceled backwards. Once the timeout has been reached, then we should sweep
+// it on-chain, and cancel the HTLC backwards.
 func testMultiHopHtlcLocalTimeout(net *lntest.NetworkHarness, t *harnessTest) {
 	ctxb := context.Background()
 

lntest/itest/lnd_multi-hop_htlc_receiver_chain_claim_test.go

@@ -20,9 +20,10 @@ import (
 
 // testMultiHopReceiverChainClaim tests that in the multi-hop setting, if the
 // receiver of an HTLC knows the preimage, but wasn't able to settle the HTLC
-// off-chain, then it goes on chain to claim the HTLC. In this scenario, the
-// node that sent the outgoing HTLC should extract the preimage from the sweep
-// transaction, and finish settling the HTLC backwards into the route.
+// off-chain, then it goes on chain to claim the HTLC uing the HTLC success
+// transaction. In this scenario, the node that sent the outgoing HTLC should
+// extract the preimage from the sweep transaction, and finish settling the
+// HTLC backwards into the route.
 func testMultiHopReceiverChainClaim(net *lntest.NetworkHarness, t *harnessTest) {
 	ctxb := context.Background()
 

lntest/itest/lnd_multi-hop_htlc_remote_chain_claim_test.go

@@ -20,7 +20,8 @@ import (
 // testMultiHopHtlcRemoteChainClaim tests that in the multi-hop HTLC scenario,
 // if the remote party goes to chain while we have an incoming HTLC, then when
 // we found out the preimage via the witness beacon, we properly settle the
-// HTLC on-chain in order to ensure that we don't lose any funds.
+// HTLC directly on-chain using the preimage in order to ensure that we don't
+// lose any funds.
 func testMultiHopHtlcRemoteChainClaim(net *lntest.NetworkHarness, t *harnessTest) {
 	ctxb := context.Background()
 

lntest/itest/lnd_multi-hop_local_force_close_on_chain_htlc_timeout_test.go

@@ -17,8 +17,8 @@ import (
 // testMultiHopLocalForceCloseOnChainHtlcTimeout tests that in a multi-hop HTLC
 // scenario, if the node that extended the HTLC to the final node closes their
 // commitment on-chain early, then it eventually recognizes this HTLC as one
-// that's timed out. At this point, the node should timeout the HTLC, then
-// cancel it backwards as normal.
+// that's timed out. At this point, the node should timeout the HTLC using the
+// HTLC timeout transaction, then cancel it backwards as normal.
 func testMultiHopLocalForceCloseOnChainHtlcTimeout(net *lntest.NetworkHarness,
 	t *harnessTest) {
 	ctxb := context.Background()

lntest/itest/lnd_multi-hop_remote_force_close_on_chain_htlc_timeout_test.go

@@ -16,9 +16,9 @@ import (
 
 // testMultiHopRemoteForceCloseOnChainHtlcTimeout tests that if we extend a
 // multi-hop HTLC, and the final destination of the HTLC force closes the
-// channel, then we properly timeout the HTLC on *their* commitment transaction
-// once the timeout has expired. Once we sweep the transaction, we should also
-// cancel back the initial HTLC.
+// channel, then we properly timeout the HTLC directly on *their* commitment
+// transaction once the timeout has expired. Once we sweep the transaction, we
+// should also cancel back the initial HTLC.
 func testMultiHopRemoteForceCloseOnChainHtlcTimeout(net *lntest.NetworkHarness,
 	t *harnessTest) {
 	ctxb := context.Background()

lntest/itest/lnd_test.go

@@ -2976,7 +2976,7 @@ func padCLTV(cltv uint32) uint32 {
 // total of 3 + n transactions will be broadcast, representing the commitment
 // transaction, a transaction sweeping the local CSV delayed output, a
 // transaction sweeping the CSV delayed 2nd-layer htlcs outputs, and n
-// htlc success transactions, where n is the number of payments Alice attempted
+// htlc timeout transactions, where n is the number of payments Alice attempted
 // to send to Carol.  This test includes several restarts to ensure that the
 // transaction output states are persisted throughout the forced closure
 // process.