No I haven't. I only read the whitepaper. And I'm unhappy with the pace of LN protocol development.
Sure we have the contract part of the protocol completed and ready to build (and there are at least two protocol implementations of it), but even the whitepaper itself notes there are a bunch of holes that need to be plugged.
For example, 8.4 Payment Routing:
It is theoretically possible to build a route map implicitly from observing 2-of-2 multisigs on the blockchain to build a routing table. Note, however, this is not feasible with pay-to-script-hash transaction outputs, which can be resolved out-of-band from the bitcoin protocol via a third party routing service. Building a routing table will become necessary for large operators (e.g. BGP, Cjdns). Eventually, with optimizations, the network will look a lot like the correspondent banking network, or Tier-1 ISPs. Similar to how packets still reach their destination on your home network connection, not all participants need to have a full routing table. The core Tier-1 routes can be online all the time —while nodes at the edges, such as average users, would be connected intermittently.
Node discovery can occur along the edges by pre-selecting and offering partial routes to well-known nodes.
We do not currently have a specification for this - every implementation is doing what it wants - and I think this it is absolutely necessary to have standard for this kind of stuff to resolve idiosyncrasies and quirks in what the description above has. (Eg: "The core Tier-1 routes can be online all the time" we haven't even defined what a tier 1 LN node is!)
[on a side note - even my ISP has crap routing, evident by my multiple attempts to load the Reply page and post this message: obviously we do not want to allow for that kind of behavior in LN.]
Another example of out-of-scope concepts is in 9.4 "Data Loss":
When one party loses data, it is possible for the counterparty to steal funds. This can be mitigated by having a third party data storage service where encrypted data gets sent to this third party service which the party cannot decrypt. Additionally, one should choose channel counterparties who are responsible and willing to provide the current state, with some periodic tests of honesty.
Neither how a data retention 3rd party would work nor how to store transaction data on a node redundantly has been defined, and quite frankly nobody can make such a service if they don't even know how the protocol would use it relative to their service. Not that I like the idea of a 3rd party intermediary in the first place - making data loss from lossy UDP connections extremely unlikely is much better.
Yet another unfinished business is in 9.2: Forced Expiration Spam, when someone expires many channels or activates too many timeouts at the same time. One solution is proposed for the former and two for the latter (the other is in section 10) but none of them are elaborated well enough to actually design a standard mitigation for this. And IMO this one is so bad that clients shouldn't be allowed to run in production without a patch to this.
I am not anti-LN (I also do not think it's an altcoin, but at the same time I feel that I can't call it canon bitcoin either since it allows for sub-satoshi payments) but frankly it should be clear that our work is not finished yet. We risk having different incompatible standards of LN implementations that segregate users to the same client if we don't have specifications for everything. Some anonymous guy was bankrolled by Square in tenths of
BTC which is 2x its worth now to develop LN and we need to see some results because
we aren't seeing any major additions. People are talking about increasing the block size as a solution for some of these vulns but this'll just introduce more drama. There are already companies like LN Labs who have their own view of how the network should be constructed and stuff like this is going to faction the network.
Let's make things simple.
-
Mitigations for spam expirations and
-
a proper, lossless, routing protocol for LN contractshas to be standardized first, and maybe then we'll see some real adoption.
Then wallets need to make it easier for users to "move" BTC between mainnet and LN.
Then the majority of wallets and especially exchanges have to implement the protocol too (do not underestimate the influence of exchanges).