Thanks for the feedback! My goal in writing this piece was to explain how channels are constructed at the protocol layer, not to provide insight on cost/benefits of the LN itself. After hearing your comments and re-reading, I definitely agree that some of my language is (unintentionally) biased. I'm going to clean up the piece and create a more hard-lined distinction between what is inherent fact vs. claims made by LN.

I'll take a look at your post and provide insight as well!

I just finished writing an article that explains Lightning Channel construction and multi-hop transfers. Looking for anyone highly versed on LN protocols to peer review for technical accuracy before I publish. Any feedback would be greatly appreciated!

https://docs.google.com/document/d/1kZcFAFGZbXUI2t0jLosRhyQ4N3dUHzWCtt5crXO728k/edit

Yes, a "channel" is really just a multisig lockup between parties. So if you wanted to deposit to your channel(s) with a single on-chain funding TX, you could specify an input with multiple destination outputs, just like in any normal BTC transaction.

With that in mind, as liquidity grows, the need to spread money across numerous channels should theoretically decrease. Multi-hop transfers are a way in which two people can pay each other w/out needing an existing channel open. If Bob wants to pay Alice w/out opening a channel with her, and they both have a mutual channel with Steve, they can still route the transaction with full guarantee of trustless settlement. This works by Bob paying Steve, who in turn pays Alice. If the relationships between participants are extremely isolated, you can keep introducing more intermediaries to form a lineage robust enough to facilitate payments.

Gotcha, so does that mean bi-directional LN channels are at a standstill until BIP 118 gets ratified?

Trying to get up to speed on Lightning... Has SIGHASH_NOINPUT been activated as a means to create refund insurance on the initial multisig deposit (as described in the Lightning Whitepaper), or have devs found an alternative workaround that doesn't require a softfork?