Re: Sprites: Payment Channels that Go Faster than Lightning

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-propose
>> s-new-design-for-bitcoin-payments/
>>
>> Paper:
>>
>> https://arxiv.org/pdf/1702.05812.pdf
>>
>
>