The author suggests that while full SegWit is not required when only one side funds the transaction, it becomes necessary when both sides contribute. They also note that full SegWit provides a feature where an unsigned transaction has the same txid as a signed transaction, which is necessary for multi-funded funding transactions that are not yet present in Lightning BOLT 1.0. When asked about the most mature Lightning implementation, the author recommends lnd, which has the most features. However, they caution that individuals experimenting with it on mainnet have BTC to spare and advise restricting oneself to testnet unless willing to lose some dust. The email also discusses the Lightning BOLT specs, which include ASCII graphics of sequence diagrams. The writer acknowledges the limitations and known-gaps in the Lightning network protocol, including the use of the same hash for the entire route, which spies can correlate if the route passes through multiple different nodes they control. The author suggests that this will be fixed in a future BOLT version. Additionally, two-sided channel funding is not currently implemented and is expected to be rejected by default by node software. The email also notes that Burchert-Decker-Wattenhofer channel factories are not yet part of the BOLT spec, but will reduce blockchain use further at the cost of a more involved process for closing channels. Finally, the email mentions that WatchTower, which would let users delegate blockchain watching to a third party, is being developed and will be added in a future BOLT version.