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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
