Quote from: DooMAD on July 30, 2018, 11:04:28 PM

As I'm not a developer, in layman's terms, how complicated a task is it to mash all the different Lightning ideas together and keep it all compatible, over multiple dev teams with their own implementations?

It certainly adds extra work to the development. Seeing as network consensus is a multi-lateral model for lightning (only individual payment paths need a sequence of consensus, the failure of which isn't critical to the overall network), there is no reference implementation like with bitcoin itself, and so lightning development resembles any other protocol development far more than bitcoin does. This makes sense overall; clightning appears to be focusing on the embedded and webstore/server markets (it uses the C language, and so it can be compiled for just about any platform), whereas lnd is targetting mobile, server and desktop (lnd is using rust, which I would assume is unlikely to work well for super simple embedded Point of Sale devices for instance), or Eclair which is mobile only.

This makes sense as a development model in lightning's case, however messy the interoperability issues are. The nuance is that the list of new ideas you mention are originating from the different teams, and they do not necessitate universal implementation. If lnd doesn't want to implement eltoo, there is no problem at the protocol level, they can continue to use the punishment protocol instead. Vice versa if ACINQ (the Eclair team) decides against implementing channel factories, Eclair can still interface with the lightning network at the level of the 1.0 protocol. So once the wrinkles in 1.0 interoperability are ironed out, it will function as a stable base layer in it's own right. Swapping out components of the protocol for enhanced substitutes, or adding additional network layers (e.g. channel factories) shouldn't be too disruptive with a stable base protocol operating (it's very close already).

Quote from: Anon136 on July 31, 2018, 12:00:45 AM

I think we all know that this person did not pull enough liquidity from the system to make it technically impossible to route payments that were not marginally large. It's just that there wasn't sufficient liquidity to overcome the shortcomings of imperfect routing. I'm skeptical that full client side routing may end up not being practical. Perhaps a hybrid system where a satisfactory level of privacy is achieved through onion routing while other hops in the routing are a collaborative effort? Not sure, just thinking out loud.

It was a little overhyped, the supposed attack withdrew much less than half the network liquidity. I think channel factories and/or cyclic node rebalancing techniques will cater for the liquidity of good actors on the network, and (yet another) proposed system for data authentication could be the building blocks to solve the bad actors problem (this would introduce rewards for serving reliable data of any type over lightning, which can be used to give nodes a routing score). There was a suggestion by the author that this could be used to simplify or remove the need for watchtowers altogether, which would be nice (I believe eltoo goes some way in that direction already)