Re: FYI: Lightning will work across ledgers

As I see it, ILP is a level of abstraction away from Lightning. In fact, if
you look at the way Lightning is being implemented you might think of it is
an implementation of many of the ILP concepts (especially the cascading
hashlocks and timeouts for security).

I certainly don't see the projects as competitive (and many of us involved
in ILP have said this before to members of both Lightning projects). In
fact, we are making an effort to ensure that ILP (an internetworking
protocol) can easily provide interop between Lightning and other networks
like Raden, Ripple or any other payment network.

ILP defines an abstraction of the "ledger layer". The layer in which value
moves around using network specific addresses, security and flows. The only
services required from the ledger layer by ILP are conditional payments;
the ability to prepare a transfer from one account to pending an expiry or
fulfillment of a condition.

What's crucial for interoperability is that there is a common condition
that all networks can use as the same condition needs to be used one all
networks for a single multi-network payment.

To that end we have already reached out to the Raden team [1] to try and
standardize on SHA-256 as this is already supported by Ripple's Payment
Channels and Lightning.

Ledgers that don't support conditional payments can be supported behind an
abstraction layer.

So in some respects I agree with Tony that Lightning is a tightly
integrated full-stack solution that is difficult to wrap your head around
entirely but I also think Lightning and ILP have different goals so it's
not actually fair to compare them.

I think our current track of making sure that Lightning is usable as
network in an ILP-based network of networks is the right one.

[1] https://github.com/raiden-network/raiden/issues/399




On 1 March 2017 at 02:28, Dimitri De Jonghe <dimi@bigchaindb.com> wrote:

> A suggestion in the spirit of inter-operability:
> maybe it makes sense to invite the Lightning folks into this discussion?
>
> - They've clearly spend a tremendous amount into bitcoin integration - and
> I can see definitely value in there.
> - I'm a big fan of simplicity and standards - and couldn't find too much
> clarity in the docs/specs from lightning. This can be due to my
> search-skills and efforts...
> - Maybe the Lightning techs can help us mapping their stack to the
> interledger stack - see if there is actual overlap and where?
>
> > But honestly, I believe that if interledger isn't compatible with
> > lightning it will be mostly for interledger's loss and not the other
> > way around (I'm aware most people here will probably disagree with
> > this point).
>
> "decentralized silo's" is exactly what interledger wants to overcome.
> It's an ecosystem effort, no inter-operability between projects (and
> legacy) means that blockchain efforts won't hit mainstream for a long while
>
> 2017-02-28 23:48 GMT+01:00 Tony Arcieri <tony@chain.com>:
>
>> On Mon, Feb 27, 2017 at 3:45 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>>
>>> > I really wish the Lightning Network folks would consider isolating and
>>> > compartmentalizing some of their ideas into a more general system, and
>>> have
>>> > talked with a few of them in person about this, but until they do to
>>> me at
>>> > least it really doesn't seem more interesting than Interledger, just a
>>> lot
>>> > more highly-coupled and intrinsically complicated.
>>>
>>> I'm sure they would be happy to listen to concrete suggestions in this
>>> reward. On the other hand, I don't think they could do much with this
>>> vague statement by itself.
>>
>>
>> I've certainly pointed them at Interledger as an example of a layered
>> payment channel protocol done well, but here's a by-the-numbers comparison
>> of the two I did in one of my slide decks:
>>
>> https://speakerdeck.com/tarcieri/a-protocol-for-interledger-
>> payments?slide=41
>>
>> Generally they have managed to produce voluminous papers and
>> documentation which doesn't specifically answer questions I'm concerned
>> with or serve to document how to actually implement the protocol (i.e. I
>> have had trouble using their documentation to answer specific questions
>> about constructions)
>>
>> Their documentation is simultaneously extremely verbose and vague. It's
>> not structured in terms of core ideas and subcomponents that can build on
>> top of it. Instead it's highly coupled, overly complex, and poorly
>> described.
>>
>> Some specific, prescriptive advice would be to extract the core ideas
>> into a self-contained document. I think they should be able to describe the
>> core protocol, in a completely self-contained manner, with enough
>> specificity to serve an implementer, in 20-30 pages.
>>
>> From there, they could layer on additional, optional functionality as
>> add-ons.
>>
>> Instead they have a complex, highly coupled protocol with many
>> intermingled components trying to do a lot of things at the same time, and
>> it's not clear how effective it is at any of them. It's hard to think about
>> any of these components in isolation.
>>
>>
>
>
> --
>
>
> Dimitri De Jonghe, PhD
> Developer
>
> +32 496 809 414 | Twitter <https://twitter.com/DimitriDeJonghe> | LinkedIn
> <https://www.linkedin.com/in/dimitridejonghe> | GitHub
> <https://github.com/diminator> | S <https://facebook.com/>kype:
> dimi.dejonghe
> [image: Logo] <https://www.bigchaindb.com/>
>
> BigchainDB GmbH
> Wichertstr. 14a, 10439 Berlin | Managing Director: Bruce Pon | Registered
> in Berlin HRB 160856B |info@bigchaindb.com | www.bigchaindb.com
>
>
>