Re: Sprites: Payment Channels that Go Faster than Lightning

We thought about this kind of flow when we were originally working on the
whitepaper. I see two main issues with it.

First, just like we realized with atomic mode, this can't really be a
"transport layer" protocol because it's not end to end. Every participant
in the path needs to support this behavior. With PSK and IPR no one except
the sender and receiver need to be aware of the protocol being used.

Second, setting this up either with a blockchain or the web presents
further issues. If you use the web it's trivial to screw some party in the
chain because the server can respond to different requests differently. If
you use a blockchain you need everyone to agree on what blockchain to use,
and then you're back to one of the original problems that prompted us to
work on Interledger in the first place: no one can agree on which
blockchain to trust.

The flow with telescoping timeouts will be a little slower and carries some
risk for connectors, but it also makes the ledger and connector behavior
very simple.

On Mon, Feb 27, 2017, 9:56 AM Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> Seems it would be a pretty easy thing to implement as an alternative
> transport layer protocol on top of ILP.
>
> i.e. The receiver provides the condition (as in IPR) or a shared-secret
> (as in PSK) to the sender but also a URL where the fulfillment will be
> released.
>
> The fulfillment URL can be passed along the chain to each ledger which can
> initiate a long-poll against the URL. As soon as the receiver gets their
> transfer they can make the fulfillment available and all ledgers release
> their locks.
>
> Assuming the transaction will only take a few seconds to complete (at
> most) this could be very efficient.
>
> Building on that, the Naming Things with Hashes spec (RFC6920) defines a
> mechanism for encoding hashes and a standard for resolving the URL at which
> the hashed content can be found.
>
> *Example:* An Interledger Payment Request from the receiver could look
> like this:
>
> {
>     "address": "ilpdemo.red.bob.b9c4ceba-51e4-4a80-b1a7-2972383e98af",
>     "amount": "10.25",
>     "condition": "ni://red.ilpdemo.org/sha-256;hd5x8kpaDDLQu-KqMyCrlsg5QJ9g9qaFr9ytTwqyCsw?fpt=preimage-sha-256&cost=12",
>     "expires_at": "2016-08-16T12:00:00Z",
>     "data": {
>         "re": "dinner the other night"
>     }
> }
>
>
> Note that the condition is expressed as an ni: URI AND has an authority
> specified. Therefor RFC6920 specifies that the preimage of the hash above
> should be available at:
>
> http://red.ilpdemo.org/.well-known/ni/sha-256/hd5x8kpaDDLQu-KqMyCrlsg5QJ9g9qaFr9ytTwqyCsw?fpt=preimage-sha-256&cost=12
>
>
>
> It therefor seems reasonable that if a ledger gets a transfer request with
> such a condition it will do an HTTP GET on that URL either with a long
> timeout or it will poll the URL at appropriate intervals to ensure it gets
> the fulfillment before it's incoming transfer expires.
>
> This doesn't preclude the ledger from getting the fulfillment via an API
> used by the receiving connector.
>
>
> On 25 February 2017 at 07:07, Jehan Tremback <jehan.tremback@gmail.com>
> wrote:
>
> This one differs from the canonical multi hop channel design in that the
> hash lock preimage is revealed publicly instead of being passed backwards
> along the chain, meaning that payments clear all at once.
>
> On Thu, Feb 23, 2017 at 2:53 PM, Tony Arcieri <tony@chain.com> wrote:
>
> Another payment channel system:
>
>
> http://www.coindesk.com/faster-than-lightning-sprite-proposes-new-design-for-bitcoin-payments/
>
> Paper:
>
> https://arxiv.org/pdf/1702.05812.pdf
>
>
>
> --

Evan Schwartz
Software Engineer
Managing Director of Ripple Luxembourg
<http:> <http:>