Re: Universal Payment Channels

Awesome paper! It's obvious that we have very similar goals in mind!

In ILP it is possible to create payment channels between any two
connectors, so you can already bypass the ledgers for repeat payments if
you like. We think that this makes sense for blockchains and any ledgers
with poor scalability (legacy systems.)

We can bypass the ledgers, but ILP does not yet let us bypass the
connectors. UPC, if I understand it correctly, does. So how would we have
to change ILP?

Essentially, we would have to extend the conditions functionality to allow
some form of partial execution. In other words, rather than sending all of
the money forward or all of the money back you'd need a way to send x% of
the money forward and 100-x% of the money back. The sender would be the one
to choose and sign x and send it to the recipient who would include it in
their final receipt.

Just to reiterate: On the ledger level it's already possible in ILP and
it's a no-brainer that you would do it. Any ILP Bitcoin connectors will
want to use Lightning or some form of micropayment channel between each
other. The open question is which optimizations (if any) we want to make on
the ILP level. There the complexity/performance trade-off is less clear to
me. Connectors can be totally stateless and centralized and we would
therefore expect them to be extremely scalable. Simplicity is critical for
any standard, so it may simply not be worth the extra complexity.
Optimizations should always be driven by need, otherwise you run the risk
that they are premature.

@Jehan: I'd love to meet you when you're back in SF and sit down with you
and Evan to chat about the different variations of UPC that we should
consider.

On Sun, Jan 3, 2016 at 11:36 AM, Jehan Tremback <jehan.tremback@gmail.com>
wrote:

> Hi, I recently presented my protocol, Universal Payment Channels, at CCC.
> Afterwards, I met Evan Schwartz, who mentioned this group.
>
> UPC is a lot like Interledger, except that ledgers hold money in escrow
> for an unlimited number of payments, instead of just one.
>
> The main effect of this is that ledgers are not involved in individual
> payments. This has a large effect on scalability because a potentially
> infinite number of payments can be exchanged between two connectors without
> any involvement of a bank, or any data saved to a blockchain. In this way
> it is similar to the bitcoin lightning network proposal.
>
> Also, individual payments can very fast, due to the non-involvement of the
> ledgers. No confirmation time or bank systems to process individual
> payments.
>
> Here's the paper if you're interested:
> http://altheamesh.com/documents/universal-payment-channels.pdf
>
> I'm also working on a routing protocol for this, which could probably be
> used with Interledger (or even Lightning) as well. It's based on AODV, and
> preserves complete anonymity of sender and receiver at the cost of
> somewhat-high network traffic. It was part of the above paper that some of
> you may have seen but I've removed it from the current draft. I'll post
> more about it later if anyone is interested.
>
> -Jehan
>