Remote node signature for HTLC-success and HTLC-timeout transactions

Question

According to BOLT #3, when constructing a HTLC output in the version of the local node (both received and offered HTLC), it requires that the payment to the local node is locked with CHECKMULTISIG opcode that requires both localhtlcsig and remotehtlcsig in order to spend it.

As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint).

So the question: suppose after I receive an HTLC from a node and I successfully pass it to the other nodes, the node that sent the HTLC to me became unresponsive. Now I will need to broadcast my version of the commitment transaction to the Bitcoin blockchain so that I can claim the funds that are locked with the payment_hash (when I receive one). But, in order to spend that output, my witness stack will need to have 0 <remotehtlcsig> <localhtlcsig> <payment_preimage>. Now, if the remote node is offline, how will I get my hands on the remotehtlcsig in order to get back the funds locked in the HTLC?

Just to provide additional details, below is a local node version of the received HTLC output according to BOLT #3

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

Answer 1

As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint).

I believe you have overlooked the commitment signed message from bolt 02. From there I quote:

When a node has changes for the remote commitment, it can apply them, sign the resulting transaction (as defined in BOLT #3), and send a commitment_signed message.

type: 132 (commitment_signed)
data:
[32:channel_id]
[64:signature]
[2:num_htlcs]
[num_htlcs*64:htlc_signature]

While we already see that signatures for all htlcs are transferred we can find the requirements further down :

A sending node: ... MUST include one htlc_signature for every HTLC transaction corresponding to the ordering of the commitment transaction (see BOLT #3).

I believe a node SHOULD NOT forward the htlc before it validated the signatures from all the htlcs of the received commitment signed.