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