Re: Sprites: Payment Channels that Go Faster than Lightning

> Since we said that conditions are just SHA-256 hashes, that extra
information would not be passed along the chain.

The condition format is still ledger specific. We've decided to make it
plain hashes for the JS ledger plugins but that doesn't preclude anyone
adding a new field that says "The receiver will post the fulfillment to the
condition at XXX url".

> requires special behavior from intermediaries

I don't think it requires special behaviur it just adds a second option for
ledgers to get the fulfillment. I.e. During setup the receiver says "I'm
gonna fulfill the final transfer but also post the fulfillment publicly at
XXX url".

The sender sees this and attaches the URL to the first transfer in a new
custom header. Any ledger that understands that header says "Yippee! I can
get the fulfillment form XXX url instead of waiting for it to be passed
down the chain."

> This proposal would not affect the worst case, because the connector
could not rely on getting the fulfillment from that URL.

I don't follow that logic. In the case where the communication breaks down
between a connector and a ledger in the middle the connector that is
waiting for the fulfillment may never get it but in the interim the next
ledger has already fetched the fulfillment directly from the receiver's
public URL so it actually doesn't matter that the connector never got the
fulfillment from the ledger where it's money is tied up.

> All of the hold times would have to stay the same.

Agreed but that's not the point. Hold times ARE the worst case. The faster
you release holds and free up liquidity the better.

I have seen HTTP long polling implemented where the connection is
established (including all TLS handshakes if required) while the resource
that is being fetched is still being prepared. The moment it is available
the client gets it and closes the connection. The implementation I saw even
exploited some very clever native platform interupts through an MSSQL DB.
(I can't recall how but it was pretty impressive both in terms of speed and
scale of connections).

For a transaction with a lot of hops this could make a significant
difference.

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

> Since we said that conditions are just SHA-256 hashes, that extra
> information would not be passed along the chain. The JS implementation will
> pass only a base64-encoded string around. (This is what I meant about this
> not being a Transport Layer feature, because it requires special behavior
> from intermediaries)
>
> Also, I don't think this would be much of an improvement. There are two
> time values to care about: the average case and the worst case. This
> proposal would not affect the worst case, because the connector could not
> rely on getting the fulfillment from that URL. All of the hold times would
> have to stay the same. There's a chance this could improve the normal case,
> but in practice I think connectors will be very fast about submitting the
> fulfillment to their source ledger so the gains would likely be minor.
>
> On Mon, Feb 27, 2017 at 3:27 PM Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> > 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
>>
>>
>> --
>
> Evan Schwartz
> Software Engineer
> Managing Director of Ripple Luxembourg
>