Re: Atomic payments

Hi David,

This is similar to Sprites
<http://www.coindesk.com/faster-than-lightning-sprite-proposes-new-design-for-bitcoin-payments>
in the sense that the AAA ledger completes the conditional payment, not
based on Bob presenting the fulfillment, but based on the CCC ledger (and
in your case also the BBB ledger) doing so. This indeed eliminates Bob's
fulfillment risk, but what makes it not really ILP-compatible is that it
requires the AAA ledger to "know about" the CCC ledger. One beautiful
aspect of Interledger chaining is that everything that happens on the AAA
ledger is local to that ledger and its direct account holders (in this case
Alice and Bob).

One thing that becomes more complicated in this approach is that if all
ledgers exchange signatures, except CCC fails to send its signature to AAA,
then Bob doesn't get paid. This means Bob now needs to trust the CCC
ledger. A solution for this would be to say all ledger need to either sign
"accept" or "reject", and nobody does anything until all ledgers have
signed one of the two. But this then allows CCC to tie up Bob's money for a
long time.

A solution to that would be to agree on a hard timeout, so the payment on
the AAA ledger is final if an agreement is reached, and if not, then it's
rolled back. But that can put Bob in the situation where ledger BBB says
"accepted" and ledger AAA says "comms network timeout". So then you're back
at needing either a notary, or forwarding of the fulfillment back along the
chain. In ILP's chaining setup, Bob always knows he has, say, 2 seconds to
submit the fulfillment to AAA after BBB has presented it to him. Ledger CCC
can do nothing to interfere with that.*)

So it may seem cumbersome to move the proof through the network
step-by-step, back from CCC through BBB, to AAA, but the advantage is that
Bob's relationship becomes much more local to himself and ledgers AAA and
BBB. The only thing CCC can do that would be bad for Bob, is to have a low
success rate, so Bob would see a lot of rolled back transactions that lead
to nothing. But at least there is no way for CCC to make Bob lose money.


HTH,
Michiel.

*) especially if Bob's connector communicates with the ledgers on an
outgoing network connection rather than an incoming one, or in the case
where Bob's connector needs to listen on a network port, make sure ledger
CCC doesn't know which ports Bob's direct neighbor ledgers use to connect.

On Fri, Aug 4, 2017 at 5:17 PM, 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
>