Re: Sprites: Payment Channels that Go Faster than Lightning

Broadcast the preimage on HAM radio

On Mon, Feb 27, 2017 at 1:52 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

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