Re: Atomic payments

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?

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.

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

Thanks,
David

On Fri, Aug 4, 2017 at 9:19 AM David Nicol <davidnicol@gmail.com> wrote:

>
> I appear to be spilling my design beans in public this season, so here is
> more, as this "full unconditional trust in the notary" requirement can
> apparently be lifted by closely tying identities and asymetric crypto. On
> the other hand, then the system requires full unconditional trust in the
> crypto. Got to trust something somehow.
>
>
> My question is, is the scheme for multi-party transactions I'm about to
> describe compatible with "ILP atomic mode"?
>
> Scheme described via timeline, capabilities of various actors are implied,
> asymmetric crypto selection and details handwaved; communication channel
> details handwaved. Currencies are designated as XXX, and are presumed to be
> managed by a well-defined interface capabable of minting purses with
> timeouts.
>
>
>    1. Alice wants to pay Bob some AAA to have Bob give some BBB to Carla,
>    who will pay some CCC to both Bob and Carla.
>    2. Expiring purses are signed by the ledgers that mint them, using
>    keys verifiably associated with the currency (not the  ledger but the
>    currency).
>    3. PART ONE: DRAFTING
>    4. Alice proposes transaction contract TC1 between Alice, Bob, and
>    Carla by:
>       1.  drafting TC1
>       2. storing TC1 as immutable data in a distributed
>       content-addressable file system
>       3. Havng AAA-ledger debit her AAA account and mint a limited
>       expiring purse containing some AAA explicitly for use in TC1
>       4. communicating a reference to TC1 to Bob and Carla along with a
>       reference to Alice's expiring purse.
>    5. Bob and Carla consider and accept the offer, which they do by
>    having BBB-ledger and CCC-ledger mint the other three limited, expiring,
>    purses and sharing references to them.
>    6. All account-holder actors now have the complete set of TC1 and all
>    input purses.
>    7. PART TWO: SETTLEMENT
>    8. the account-holders present the complete set of contract plus
>    inputs to the three currency-ledgers.
>    9. the ledgers now communicate with each other to collect
>    ledger-signatures indicating that each ledger has received the complete set
>    of references to immutable data.
>    10. purse contents are transferred at all currency ledgers on receipt
>    of ledger-signatures from all other participating ledgers.
>
>
> My scheme is clearly different from the general ILP paradigm of
> communications between ledgers holding accounts in the same currency -- I
> would treat "USD at Chase" and "USD at WellsFargo" as different currencies,
> as different as Ethereum and McDonald's Gift Certificates, or any other
> currencies that are not the same -- 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.
>
> Thank you for your patience
>
> David Nicol
>
>
> On Thu, Jun 29, 2017 at 8:46 AM, Stefan Thomas <stefan@ripple.com> wrote:
>
>>
>> In atomic mode, all participants along the payment chain have to have
>> full unconditional trust in the notary. Since the set of all possible paths
>> contains all possible combinations of participants, that means that in
>> order to be able to use atomic mode all of the time, there must be at least
>> one notary that is trusted by all people in the world. Otherwise, we may
>> run into situations where a liquidity path is available, but no valid
>> notary can be selected.
>>
>> It is possible to use multiple notaries in a payment, but that actually
>> doesn't make the trust problem easier and arguably makes it harder. If we
>> assume f=1 (i.e. one notary may fail), then we now need all participants to
>> trust notaries such that none of the notaries they trust would ever collude
>> with any other notary they trust. Granted, that's a weaker requirement, but
>> now we need at least four notaries that the entire world trusts (in this
>> weaker sense.)
>>
>> Often you will have payment chains where you start on a constrained
>> device or some kind subsidiary ledger. And often in those cases, it will
>> make sense to defer to the superior ledger. It's certainly conceivable that
>> at some point in the future all smaller ledgers on the sending side will
>> defer-right and all smaller ledgers on the receiving side will defer-left.
>> If the larger networks in the center have peering agreements like the ones
>> we are planning to have for RippleNet, that means that many or most
>> payments may well end up being fully atomic.
>>
>
> --
> everything has to be just so or the magic won't work
>