Re: FYI: Lightning will work across ledgers

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