The capacity of the lightning network seems to ride on the "trust" of the counterparty you are opening a channel with along with the additional layer of trusting a watchtower to keep your funds safe.
No. It is designed to be trust minimized so that you don't have to trust your counterparty as long as you stay online and monitor the chain for attempted channel closes with revoked states (old commitment transactions). With onchain Bitcoin you need to keep your private key safe, you aren't devoid of responsibility. With Lightning you need to keep your private key safe and stay online. Additional responsibilities yes but it is not designed to be a trusted protocol.
Transactions are sent and received over a period of a month via a signed transaction (script signature?). Outdated transactions are overwritten by newer transactions, also called a justice transaction?
A channel is opened with an onchain transaction sending to a 2-of-2 multisig address controlled by you and the counterparty. Then you exchange commitment transactions as your balance and your counterparty's balance changes. New transactions are called commitment transactions not justice transactions. A justice transaction is only used as a response if your counterparty tries to close the channel with an old commitment transaction (revoked state).
If Bob decided to be malicious and try to execute an older justice transaction say a few weeks back where he owned more of the BTC in the channel, he can, only if:
- he knows that none of the members have a watchtower running.
- he knows that none of the members have a watchtower running.
knows that all the members are offline at a given time.
If he broadcasts an old commitment transaction it can be mined and included in a block. It is the responsibility of Bob's counterparty to watch out for this though one can outsource this responsibility.
From there he can close all the channels among these 4 party members.
No. All channels are between two parties. Payments can be routed through multiple channels but every channel is only the business of two parties. Channel factories change this and increase the number of participants but these are only theoretical at time of writing and aren't implemented anywhere (they generally require the ANYPREVOUT sighash flag).
With this type of multiple layers of trust, I can't foresee most people putting up large BTC channels except for exchanges themselves. A normal person wouldn't be managing their own watchtower, but that means they would need to pay for a watchtower subscription from a 3rd party. Not exactly scalable if one requires the involvement of a 3rd party to keep your funds safe, imo.
If you are an edge node and not a routing node you may only be paying in one direction and not receiving. If this is the case you don't have to worry about the online requirement because your balance is only going down over time and your channel counterparty doesn't gain anything by broadcasting a revoked state. I think most users of the network will be edge nodes and won't be routing nodes for some of the reasons you suggest.
What are some proposed solutions so far in 2021-Nov to this problem to get BTC lightning more widely adopted?
I think the Lightning community seems optimistic about current adoption with the developments in El Salvador and Lightning payments in gaming seeming to catch on. There is still a lot of work to do to improve the protocol and build out the ecosystem and so too much adoption would also likely be a problem.
It seems some type of decentralized watchtower system needs to exist without BTC users needing to pay some type of subscription fee.
I'm not optimistic that there could be a decentralized solution. When you require a service you are generally better paying a particular party (or multiple parties) and holding them accountable rather than leaving it to the "crowd".
I'm still understanding the limitations of Lightning. So please bear with me if some of my assumptions aren't accurate.
I'd encourage you to read more on how commitment transactions and HTLC (hash timelocked contracts) work. There are various resources discussing these on this site, in the BOLTs or elsewhere.
