Re: failures during the preparation phase (universal mode)

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