Re: Sprites: Payment Channels that Go Faster than Lightning

On 27 February 2017 at 09:46, 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.
>

I really like this pattern of using RFC6920, the ni URI scheme in
conjunction with .well-known locations.

I am curious, is the content at the .well-known location JSON-LD, or some
other format?


>
>
> 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
>>>
>>
>>
>