How do you know that Block, the Merket Root & the hashes in the path are authentic? I went through this Q &amp; A on Merkle Root
What is the Merkle root?

And several others on the Merkle Root &amp; the Merkle Tree. I understand what is a Merkle Tree &amp; how you can take use your transaction hash &amp; other hashes in the path to the root to verify if it's consistent.  

However, you get the Merkle Root &amp; all of all other path nodes from a node you don't essentially trust, right? So what's the point of this verification? The whole block itself or the Merkle Root or the path hashes may be fake. The only way this verification makes sense is if you already have a later block you trust &amp; the previous hash from that points to this Merkle Root. However, this does not make sense to me - how will you trust that block in the first place?   

What am I missing?
Forget about the Merkle tree. Assume that instead, the block header would just contain a hash of the concatenation of all transactions.

A lightweight node could then download all headers, verify their proof of work, and make the assumption it has seen the longest chain. It is now convinced it has seen the chain the network accept. This is different from a full node, which does not assume a chain is accepted until it has seen all block data and verified every single transaction.

Now the lightweight client decides to ask peers for the actual block data. When it receives a blocks' transactions, it knows they actually match what the block header committed to, as it can recompute the hash, and compare it to the value in the header.

But what if the lightweight node is not interested in all transactions? BIP37 introduces the concept Bloom filtered blocks, where a lightweight node can reveal what keys/transactions/addresses it is interested in, and the full node it is downloading from will only give the transactions that match the filter.

Unfortunately, if the lightweight node does not download all transactions, there is no way to know whether they match the hash in the header, and as such, the full node could lie, and include transactions that are not actually present in the chain.

Enter the Merkle tree.

Instead of just storing a hash, we store the root of a Merkle tree. The full node can now for each matched transaction include the hash values that transaction's hash is combined with, to prove that the transaction is in fact included in the tree, despite the fact that the lightweight node only knows the root.