Re: FYI: Lightning will work across ledgers

Interesting. I hadn't been familiar with the term "path vector", AFAIK, all
distance vector protocols except for RIP and maybe Batman could be termed
path vector protocols.

On Wed, Feb 22, 2017 at 6:55 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> Great summary! Thanks Evan
>
> On 22 February 2017 at 09:47, Evan Schwartz <evan@ripple.com> wrote:
>
>> It made me realize that inter-blockchain Lightning would end up quite
>> functionally equivalent to ILP + crypto conditions.
>>
>>
>> I very much agree with this point from Ryan, and Jehan's and Tony's
>> points about simplicity being key.
>>
>> If you frame the issue of interoperability between blockchains/ledgers in
>> a certain way, the way I see it is that you'll come to something like 6
>> major decisions. And if you pick a certain option at each of those major
>> forks in the road, you'll effectively end up at Interledger.
>>
>> The first split is probably the biggest, and that's whether you build
>> internetworking into blockchains/ledgers or build a separate component to
>> handle internetworking. In approaches like Cosmos
>> <https://cosmos.network/whitepaper> / Polkadot <http://polkadot.io/>,
>> blockchains must be specifically designed to be part of those systems and
>> must be aware of or subservient to one or more other blockchains. This
>> could allow a deeper type of integration, but comes with a complexity
>> tradeoff. With Lightning / Interledger, internetworking is handled by a
>> separate component (Lightning nodes or Interledger Connectors). This is
>> simpler and can incorporate a wider variety of ledgers, but is primarily
>> useful for trading assets of value across ledgers. Interledger also uses an
>> abstraction over the functionality expected from the ledger layer (instead
>> of building simpler ledgers to imitate blockchains) and tries to minimize
>> the functionality required from the ledger layer.
>>
>> If you are going the route of having separate internetworking systems,
>> the key building block you need is the Lightning / Interledger /
>> Cross-Chain Atomic Transaction flow. This flow ensures that senders cannot
>> lose money in multi-hop transactions, no matter who the intermediaries are.
>> Shifting the risk from senders and recipients to the intermediaries is what
>> enables us to even start conversations about routing and all of the other
>> issues below. The fact that many projects have settled on the same
>> transaction flow seems to suggest that it's just this idea's time.
>>
>> Given the idea of connectors and the transaction flow, some of the other
>> major decision points are as follows. Those in bold are the choices that
>> currently make up the Interledger approach.
>>
>>    1. Crypto Algorithm(s) for Conditional Transfers
>>       - Crypto Conditions - flexible, combinable, upgradeable, but
>>       relatively complicated. Spec here
>>       <https://tools.ietf.org/html/draft-thomas-crypto-conditions-02>
>>       - *SHA-256* - lowest common denominator. Arguably, you can only
>>       make payments across ledgers that support the same condition type anyway so
>>       you might as well standardize on this. See discussion here
>>       <https://github.com/interledger/rfcs/issues/153>
>>       - Something else - Stefan had a good way of describing the options
>>       here <https://github.com/raiden-network/raiden/issues/399>
>>    2. Ledger-Agnostic Addresses
>>       - Centralized Authority - something like IANA for the Internet
>>       - Decentralized Authority - blockchain or DHT
>>       - *No Authority* - using conditional transfers you know
>>       definitively if payments are routed to the correct place, so address
>>       collisions are arguably less of a problem. See spec here
>>       <https://github.com/interledger/rfcs/pull/154>
>>    3. Packet Format
>>       - Binary (Protobuf, CBOR, ASN.1/OER, custom) - more efficient,
>>       less developer-friendly. Some of these options are more widely supported
>>       (Protobuf) and some are simple enough that they could be implemented from
>>       scratch (OER)
>>       - Text (JSON, XML, custom) - human-readable and easier for
>>       development but less efficient and slower
>>       - *ASN.1/OER + JSON* - use a simple binary format that is fast to
>>       encode/decode and to write a parser for, and then also define a JSON
>>       version for development and JSON-based ledger protocols. See discussion
>>        here <https://github.com/interledger/rfcs/issues/146>
>>       4. Routing Protocol (thanks to Michael Warnock for these points)
>>       - Link-state - every router must know about all of the others, so
>>       this doesn't scale to larger networks
>>       - Distance-vector - uses the cost of routes to make routing
>>       decisions, close to what we have implemented in the ilp-connector
>>       <https://github.com/interledgerjs/ilp-connector> now
>>       - *Path-vector* - has more information available for preventing
>>       the pathological cases that come up in IP routing, and is used in BGP,
>>       which has the most analogous use case to ours
>>       - Hybrid - something like what Bitfury suggests in their whitepaper
>>       <http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf>
>>    5. Layering vs Bundling
>>    - Built-in Privacy - Lightning has onion routing built in to the core
>>       protocol
>>       - Built-in Identity - traditional payment protocols include
>>       information about who is sending money and why
>>       - *Bare Minimum interledger Protocol* - core protocol only
>>       includes the information necessary to make routing decisions. Other
>>       functions, like privacy and identity, are handled by layers above and below
>>       the interledger layer
>>    6. Prefunded vs Postfunded Channels
>>       - Prefunded - as far as I know, Lightning requires all channels to
>>       be prefunded. This means there is less risk but it's also more expensive to
>>       tie up capital for this purpose
>>       - Postfunded - credit or "trustlines" are cheaper because they do
>>       not require capital but they do come with counterparty risk. May be more
>>       appropriate in circumstances where the participants have a closer
>>       relationship
>>       - *Both *- Interledger abstracts away the difference between bond-
>>       and credit-based bilateral relationships, letting users and connectors
>>       choose which one makes the most sense for their use case, trust model, and
>>       level of risk tolerance
>>
>> A couple more decisions that one could argue should be part of this set
>> are what number format to use for expressing interledger amounts, whether
>> quotes are locked or not, whether routers are stateless, etc.
>>
>>
>> On Wed, Feb 22, 2017 at 4:59 AM Tony Arcieri <tony@chain.com> wrote:
>>
>> On Tue, Feb 21, 2017 at 3:09 PM, Jehan Tremback <jehan.tremback@gmail.com
>> > wrote:
>>
>> All channel implementations are dealing with a similar concept, and just
>> do it in different ways to work on different platforms and have different
>> capabilities. One of the main things that sets Lightning apart is that the
>> code is very complex, to accommodate the limitations of Bitcoin script.
>> Sure, you *could* use various layers and adapters to make it work, but
>> would you want to? I'm guessing most people will want to use something that
>> is tailored to their use-case and easy to build upon.
>>
>>
>> Yes, +1 this. While it's great that Lightning can work across ledgers,
>> the one problem you claim as unsolved (exchange rates) is already solved by
>> Interledger, and Interledger provides a substantially simpler and much more
>> general, *layered* implementation strategy.
>>
>> 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.
>>
>> --
>>
>> Evan Schwartz
>> Software Engineer
>> Managing Director of Ripple Luxembourg
>>
>
>