Re: Sprites: Payment Channels that Go Faster than Lightning

> This doesn't preclude the ledger from getting the fulfillment via an API
used by the receiving connector.

What I meant by this is it seems pretty trivial to supplement any existing
transport protocol with this. I.e. If the receiver supports publishing the
fulfillment via the Web they use a condition in the ni:// form with a
specified authority.

Any ledger that wants to can poll the URL for the fulfillment and
potentially get it faster than waiting for it to be delivered via the
notification of a transfer on it's outgoing ledger.

I can't see any risks in this approach. Am I missing something?

On 27 February 2017 at 11:09, Evan Schwartz <evan@ripple.com> wrote:

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