- From: Evan Schwartz <evan@ripple.com>
- Date: Mon, 28 Aug 2017 21:31:29 +0000
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Enrique Arizon Benito <enrique.arizon.benito@everis.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CAONA2jXw=xVbJY6t3-MN+jhQbCbS2MfYbe0A2YQsEUwMn-Tx_w@mail.gmail.com>
Sure, keeping the state of an HTLA in some kind of database and validating conditions isn't *required*, but is there any other sensible way to implement it? If not then I think we should talk about it using the RFC "SHOULD" because those are such massive and unnecessary footguns otherwise. On Mon, Aug 28, 2017 at 5:25 PM Adrian Hope-Bailie <adrian@hopebailie.com> wrote: > I really dislike how we keep saying that ILP "requires" X or Y with regard > to the HTLA or talk about protocol requirements in terms of implementation > details. > > For example, I disagree with with 1. ILP does not have any requirements > with regards to implementation details like where the HTLA status is kept. > If we say ILP requires it be kept in the ledger or connector plugin that is > incorrect because those are implementation details. ILP only requires that > the condition and fulfillment are passed along. > > I agree with 2 because that is a functional requirement not an > implementation requirement. > > I think Enrique is correct regarding 3.2. The protocol has no requirement > that connectors use the conditions and fulfillments. An ILP payment will > still work if one of the host-to-host transfers in the middle ignores the > condition and fulfillment with respect to the validity of the transfer and > simply passes them on to the next host. > > > On 25 August 2017 at 06:50, Evan Schwartz <evan@ripple.com> wrote: > >> 1-3.1 are correct. >> >> 3.2 Connectors use conditions and fulfillments even in trustlines. They >> only update their balance with their peer when they agree that the (valid) >> fulfillment has been submitted before the timeout. >> >> 4 is kind of correct. The current view is that the most important thing >> to standardize are the protocols that will be used across ILP "Autonomous >> Systems", and that's more likely to be universal mode than atomic. Atomic >> is very useful for removing connector risk but since it requires commonly >> trusted parties anyway, it's slightly less important to have widespread >> standards for how you do it. That said, I think there will be standards for >> atomic ILP, so if others are interested in working on that we can >> definitely start some discussion about it. >> >> On Fri, Aug 25, 2017 at 3:39 AM Enrique Arizon Benito < >> enrique.arizon.benito@everis.com> wrote: >> >>> Hi, >>> >>> Trying to keep in sync with this long thread "An attempt to clean up the >>> protocol architecture" and the current state of ILP in general, I just >>> would appreciate if someone can correct me about next claims: >>> >>> 1. During the payment process, ILP requires to keep the current HTLA >>> status in a ledger (using the escrow). >>> >>> 1.1 If the ledger does not support HTLA this status must be kept in >>> the connector plugin. >>> >>> 2. During the payment process, fulfillments and errors must be returned >>> through the same payment path that initiated the payment (same set of >>> connectors/ledger) forcing to keep an status on each connector mapping >>> incomming to outgoing transfers. >>> >>> 3. For trust-lines, connectors can connect without a "real" >>> intermediate ledger, but they will still use a plugin that certainly will >>> act as a virtual ledger to keep balances. >>> >>> 3.1 That means a ledger always exists, either real or virtual. >>> >>> 3.2 For trust-lines, connectors are allowed to ignore >>> conditions/fulfillments but must still forward them. >>> >>> 4. There is no support for atomic mode in ILP, but can be build in a >>> non-standard (non-ILP-defined) way on-top of it using for example an >>> external arbiter for all connectors in the payment proccess. >>> >>> Regards, >>> >>> Enrique >>> >>> ________________________________ >>> >>> AVISO DE CONFIDENCIALIDAD. >>> Este correo y la información contenida o adjunta al mismo es privada y >>> confidencial y va dirigida exclusivamente a su destinatario. everis informa >>> a quien pueda haber recibido este correo por error que contiene información >>> confidencial cuyo uso, copia, reproducción o distribución está expresamente >>> prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por >>> error, le rogamos lo ponga en conocimiento del emisor y proceda a su >>> eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo. >>> >>> CONFIDENTIALITY WARNING. >>> This message and the information contained in or attached to it are >>> private and confidential and intended exclusively for the addressee. everis >>> informs to whom it may receive it in error that it contains privileged >>> information and its use, copy, reproduction or distribution is prohibited. >>> If you are not an intended recipient of this E-mail, please notify the >>> sender, delete it and do not read, act upon, print, disclose, copy, retain >>> or redistribute any portion of this E-mail. >>> >> -- >> >> Evan Schwartz >> Software Engineer >> Managing Director of Ripple Luxembourg >> > > -- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg <http:> <http:>
Received on Monday, 28 August 2017 21:32:05 UTC