[Lightning-dev] SegWit and LN

[ZmnSCPxj]

Good morning Praveen,

For some background please consider the article I wrote:
https://zmnscpxj.github.io/offchain/generalized.html

Especially "Requirements on the Blockchain".

For cases where the funding transaction is funded by only one side, then full SegWit is not needed, "only" some kind of malleability fix.  However, there is the possibility in the future of funding transaction being funded by both sides, and that requires full SegWit.  Full SegWit is not only a malleability fix, but also provides the feature that an unsigned transaction has the same txid as a signed transaction. This is necessary for multi-funded funding transactions (not yet present in Lightning BOLT 1.0).

> Which is the most mature Lightning implementation right now? I want to setup a lightning node and start experimenting with it.

I believe lnd has the most features. There are even a few brave individuals who are experimenting with it on mainnet. Please note that those individuals have mainnet BTC to spare for this and will not miss those BTC if it becomes locked due to bugs (they are mostly using UTXOs they consider to be "dust" I believe), so in general you should restrict yourself to testnet for now unless you have some dust you are willing to lose.

> Also did anybody create a protocol diagram of how lightning works? (similar to the one below about SSL)

The Lightning BOLT specs have many sequence diagrams: https://github.com/lightningnetwork/lightning-rfc

They are ASCII graphics, but are understandable.

> [image.png]
>
> I have seen higher level diagrams but as evident from my previous mails, they only touch the basic concepts and not the exact flow of events leaving many doubts.  It would be really helpful to make such a detailed flowchart/diagram if one does not exist already.
>
> Also, what are the current limitations/known-gaps in lightening network protocol? When can its guarantees fail?

There are many. A few include:

1. The same hash is used for the entire route. Spies who have many nodes can correlate routes with the same hash if the route passes through multiple different nodes they control.  This is fixable and will be fixed in a future BOLT version.
2. Funding of channels is currently one-sided only. This is safer in general as some measure of trust and anti-DoS and so on is needed for two-sided funding of channels (i.e. if you blindly accept requests for two-sided funding, and I am much richer than you, I can start up a node or hundreds of nodes, have them request two-sided funding channels with you, then take all of them offline, leaving you with BTC locked in unuseable channels which you will have to unilaterally close (which requires delays measured in hours or days as part of the protocol)). Two-sided channel funding will probably be rejected by default by your node software and would have to be specifically enabled for nodes you trust (although that probably will not be part of the protocol itself, just the design of node software).  This will be added in a future BOLT version.
3. Burchert-Decker-Wattenhofer channel factories are not yet part of the BOLT spec. This will reduce blockchain use even further, at the cost of a more involved process for closing channels.  This will be added in a far future BOLT version, because this is even newer tech than Lightning and will still need more design and so on.
4. If you do any receives at all (note that routing through your node is a receive+send) you need to watch the blockchain for attempts at theft. There is some work being done, called WatchTower, that would let you delegate this watching to a third party on your behalf. You do not need to watch the blockchain if you use your node strictly for sending only (I believe Eclair has a mode for this, intended to be used for mobile devices).  This WatchTower will be added in a future BOLT version.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180102/2f714082/attachment.html>