Re: FYI: Lightning will work across ledgers

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