From corne at bitonic.nl Mon Feb 12 13:30:07 2018 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Mon, 12 Feb 2018 14:30:07 +0100 Subject: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning In-Reply-To: <87h8qmwohh.fsf@gmail.com> References: <1518171320.5145.0.camel@ultimatestunts.nl> <87h8qmwohh.fsf@gmail.com> Message-ID: I was thinking that, for that use case, a different signed invoice could be formulated, stating * several payment hashes with their corresponding amounts * the obligation of signer to deliver Z if all corresponding payment keys are shown * some terms to handle the case where only a part of the payments was successful, e.g. an obligation to refund The third item is a bit problematic: in order to distinguish this case from a complete success, the payee would have to prove *absence* of successful transactions, which is hard. Absence of successful transactions can only be declared by the payer, so in order to reliably settle *without* going to court first, the payer should sign a declaration stating that certain transactions were canceled and that the other ones should be refunded. This can be another invoice. So, the original invoice states: * several payment hashes with their corresponding amounts * if all corresponding payment keys are shown: the obligation of to deliver Z, UNLESS stated otherwise by an invoice signed by -- signed by But if a payment partially fails, it can be refunded cooperatively with an invoice created by payer: * declares which of the original payments were successful (with payment keys) and which were not * replaces the obligation of to deliver Z with an obligation to refund the successful transactions * several payment hashes with their corresponding amounts * if all corresponding payment keys are shown: cancel the obligation of to refund -- signed by Maybe this can be repeated iteratively if necessary; hopefully the not-yet-settled amount will converge to zero. Important advantage: this only requires changes to the invoice format, not to the network protocol. The point is: in this use case, the court is apparently the final point of settlement for invoices, just like the blockchain is for the other channels in the route. IANAL, but I think the "scripting language" accepted by courts is quite flexible, and you can use that to enforce atomicity. With the construction described above, you can either refund cooperatively (and collect evidence that refund has happened), or, if that fails, go to court to enforce settlement there. CJP Op 12-02-18 om 10:23 schreef Christian Decker: > CJP writes: >> Can you give a use case for this? >> >> Usually, especially in the common case that a payment is done in >> exchange for some non-cryptographic asset (e.g. physical goods), there >> already is some kind of trust between payer and payee. So, if a payment >> is split non-atomically into smaller transactions, and only a part >> succeeds, presumably they can cooperatively figure out some way to >> settle the situation. > The scenario that is commonly used in these cases is a merchant that > provides a signed invoice "if you pay me X with payment_hash Y I will > deliver Z". Now the user performs the payment, learns the payment_key > matching the payment_hash, but the merchant refuses to deliver, claiming > it didn't get the payment. Now the user can go to a court, present the > invoice signed by the merchant, and the proof-of-payment, and force the > merchant to honor its commitment. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev