Re: Atomic payments

On Fri, Aug 4, 2017 at 11:15 AM, David Fuelling <fuelling@ripple.com> wrote:

> Hi David,
>
> Some thoughts below...
>
> > ...but I'm writing to ask if the atomic purse based multi-party
> cryptographic protocol described
> > above would be interoperable and semantically compatible with the ILP
> "atomic mode" as
> >  currently defined.
>
> One way I like to think about ILP Atomic-mode is that it's essentially a
> consensus problem that is complicated by the concept of "expiration" -- in
> other words, how to get a series of N participants to agree on the truth of
> a payment's final state -- did it execute, cancel, or expire?
>

I've got no cancel, just execute and expire. Cancel can be added on with
introduction of a cancel token that would have to be signed and distributed
by a participant, which other participants would respond to any completion
messages with, prior to execution.


Using a centralized notary solves this problem because each participant
> simply asks the notary about the outcome of a payment, and _eventually_ all
> participants will come to the same answer.
>
> An alternative Atomic-mode setup would be something distributed, which
> works the same way except now we have to introduce some kind of distributed
> consensus algorithm for all payment participants to come to agreement.
>

the execution condition is, (contract, all purses, sigs from participating
currency-ledgers) is received. We don't care about ordering.



>
> Perhaps I'm not understanding your algorithm fully, but bullet-point 9 is
> most interesting to me because it seems to be the main consensus mechanism
> in your proposal. However, how does it solve the distributed consensus
> problem? Is the algorithm fault-tolerant? Is it Byzantine Fault Tolerant?
> How many faults? Also, perhaps bullet-point 4.2 helps address some of this,
> using a DCAF? But what about expiration agreement?
>

I do rely on reliable channels between the currency-ledgers. Extending the
condition, from the point of view of a ledger making an execute/expire
decision, from "I have shared my signed execution readiness indicator and
have received all other ledgers' such" to "I have acknowledged receiving
signed execution readiness indicators from all other participating ledgers
and also i have received acknowledgements from all other participating
ledgers to which I have sent my own signed execution readiness indicator"
should solve fault tolerance, thank you for asking that. As the
acknowledgements would be signed data also, and the scheme trusts its
crypto, full-mesh communications are not required: the signed acks (and
everything else) may be passed by spanning-tree.



> I'm curious to hear more thoughts on some of the edges of your proposed
> algorithm. Specifically, under which well-defined circumstances could
> settlement decisions become inconsistent between payment participants?
>

Aside from communication faults, there has to be a decision made about the
tolerances about when expiration is recognized, that is, how long, if at
all, after the expiration time, do ledgers continue to accept
back-timestamped readinesses and readiness acks? Those two deadline
extensions could be included as required parameters in the contract object,
but that would make the protocol more complicated, so lets say all acks
have to be received everywhere by the deadline, and if we're close to the
deadline (like more than halfway there from the proposal timestamp) there
could be an extended acknowledgement phase and a last chance to cancel,
before calling in the humans to sort things out.

Looks like the contract data object will have to include

   - human-readable descriptive title
   - initiation timestamp in ISO-8601 datetime
   - expiration timestamp in ISO-8601 datetime format
   - list of parties and what each party will be putting in, and getting
   out; reference to public key each party will be signing with
   - association of currencies with public keys currency-ledgers will be
   using
   - cancellation token, can by signed by any participant; signed
   cancellation token will be issued in response to any queries concerning
   status