- From: Stefan Thomas <stefan@ripple.com>
- Date: Fri, 11 Mar 2016 11:24:44 -0800
- To: Xavier Vas <xavier@tr80.com>
- Cc: Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CAFpK0Q1XYxikdbL+CbrFB6GmfLLZ9+UJrsEiLVcvNq2Q0=hHFw@mail.gmail.com>
> The originator will initiate another preparation phase with the same connectors? Or another proposal? Or find different connectors? I guess all the options are open. Yes, these are all options. > IMHO that makes the preparation phase a phase of trial and error, much like -- presumably -- the proposal and preceding path finding phases. If so, why bother differentiating between these? Where is the necessity for a more complex multi-phase protocol? Complexity killed the cat as they say so its necessity should be well-reasoned. Great point. As you pointed out on IRC, the Nested Transfers [1] spec is essentially a realization of your idea here. [1] https://docs.google.com/document/d/1zTLQLBx0p6-Ds9Ki8nCaVBdXUK4mbJZDQOaz83n6VY8/edit On Mon, Nov 23, 2015 at 2:24 AM, Xavier Vas <xavier@tr80.com> wrote: > Hi, > > I'd like some clarification on the preparation phase in universal mode. > I assume a connector can, when receiving a preparation message from a > previous connector, deny performing the escrow on its outgoing ledger > and instead pass an error message back, or just let the escrow timeout > on its incoming ledger expire. Either way, this will percolate back to > the payment originator and the payment has failed its preparation phase. > > Reasons for failing to execute the escrow on behalf of a connector could > be technical problems etc. but most likely, I assume, not having enough > funds at its disposal to execute the escrow. This can happen in spite of > a confirmation during the proposal phase, as confirming funds to be > available does not mean setting aside said funds for a later > transaction. It can at best be a good guess that involves parameters > such as funds available, rate of transactions processed, typical delays > between proposal and preparation phases and -- most importantly -- > likelihood of customers actually following up a proposal with an actual > transaction, because they can propose several paths and only execute > one, if even, e.g. the one with the lowest fees. > > The latter I guess would be like airline passengers booking seats on > several flights and only showing up for one at best. Airlines compensate > for this behavior by overbooking their flights, which then in turn may > lead to booked passengers being turned down. Booking a seat is the > proposal phase and showing up the preparation phase of the transaction. > > Either way, if a payment fails during the preparation phase, what then? > The originator will initiate another preparation phase with the same > connectors? Or another proposal? Or find different connectors? I guess > all the options are open. The next attempt could also, conceivably, fail > again then. > > IMHO that makes the preparation phase a phase of trial and error, much > like -- presumably -- the proposal and preceding path finding phases. If > so, why bother differentiating between these? Where is the necessity for > a more complex multi-phase protocol? Complexity killed the cat as they > say so its necessity should be well-reasoned. > > Thanks > > Xav > > > >
Received on Friday, 11 March 2016 19:25:35 UTC