Re: Sprites: Payment Channels that Go Faster than Lightning

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

I'd recommend it is simply the binary content of the fulfillment (
application/octet-stream)


On 27 February 2017 at 13:59, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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