W3C home > Mailing lists > Public > public-interledger@w3.org > February 2017

Re: Sprites: Payment Channels that Go Faster than Lightning

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Mon, 27 Feb 2017 16:27:57 +0200
Message-ID: <CA+eFz_LbAWFrtvJpnFYdRYURcqHHCZcwW-eZnfTTpXoq3xvz_Q@mail.gmail.com>
To: Evan Schwartz <evan@ripple.com>
Cc: Jehan Tremback <jehan.tremback@gmail.com>, Tony Arcieri <tony@chain.com>, Interledger Community Group <public-interledger@w3.org>
> 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
Received on Monday, 27 February 2017 14:53:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:14:00 UTC