- From: Jehan Tremback <jehan.tremback@gmail.com>
- Date: Tue, 28 Feb 2017 13:20:04 -0800
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Evan Schwartz <evan@ripple.com>, Tony Arcieri <tony@chain.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CABG_PfRBieHHK1AKkMmLswM00SrNfxSpNE-3qCUbqi859bwE+A@mail.gmail.com>
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 >> > >
Received on Tuesday, 28 February 2017 21:20:42 UTC