📅 Original date posted:2018-02-12
📝 Original message:
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 <payee>
to deliver Z, UNLESS stated otherwise by an invoice signed by <payer>
-- signed by <payee>
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 <payee> 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
<payee> to refund
-- signed by <payer>
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 <cjp at ultimatestunts.nl> 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
Corné Plooy [ARCHIVE] /
npub1ly…cdx6n
2023-06-09 12:49:04
in reply to nevent1q…q2jl
Author Public Key
npub1ly5vrg5ylhdkxrkj824jhlnfsy2z8fvlg8wcc0jqc4aezma6majsycdx6nPublished at
2023-06-09 12:49:04Event JSON
{
"id": "dbc04f40badd4023145756290bb26d5977eb184943ee10e96a6d0143bfa681f1",
"pubkey": "f928c1a284fddb630ed23aab2bfe69811423a59f41dd8c3e40c57b916fbadf65",
"created_at": 1686314944,
"kind": 1,
"tags": [
[
"e",
"51bc92b7fa9a7d9c09bb73c2362ca09a737a241a77a68cd95503c148136969eb",
"",
"root"
],
[
"e",
"a2496f066e63cd69decbd57689f806c6ae9e9136db2190e06cc3d4f2c10c019b",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-02-12\n📝 Original message:\nI was thinking that, for that use case, a different signed invoice could\nbe formulated, stating\n\n* several payment hashes with their corresponding amounts\n\n* the obligation of signer to deliver Z if all corresponding payment\nkeys are shown\n\n* some terms to handle the case where only a part of the payments was\nsuccessful, e.g. an obligation to refund\n\n\nThe third item is a bit problematic: in order to distinguish this case\nfrom a complete success, the payee would have to prove *absence* of\nsuccessful transactions, which is hard. Absence of successful\ntransactions can only be declared by the payer, so in order to reliably\nsettle *without* going to court first, the payer should sign a\ndeclaration stating that certain transactions were canceled and that the\nother ones should be refunded. This can be another invoice.\n\n\nSo, the original invoice states:\n\n* several payment hashes with their corresponding amounts\n\n* if all corresponding payment keys are shown: the obligation of \u003cpayee\u003e\nto deliver Z, UNLESS stated otherwise by an invoice signed by \u003cpayer\u003e\n\n-- signed by \u003cpayee\u003e\n\n\nBut if a payment partially fails, it can be refunded cooperatively with\nan invoice created by payer:\n\n* declares which of the original payments were successful (with payment\nkeys) and which were not\n\n* replaces the obligation of \u003cpayee\u003e to deliver Z with an obligation to\nrefund the successful transactions\n\n* several payment hashes with their corresponding amounts\n\n* if all corresponding payment keys are shown: cancel the obligation of\n\u003cpayee\u003e to refund\n\n-- signed by \u003cpayer\u003e\n\n\nMaybe this can be repeated iteratively if necessary; hopefully the\nnot-yet-settled amount will converge to zero.\n\n\nImportant advantage: this only requires changes to the invoice format,\nnot to the network protocol.\n\n\nThe point is: in this use case, the court is apparently the final point\nof settlement for invoices, just like the blockchain is for the other\nchannels in the route. IANAL, but I think the \"scripting language\"\naccepted by courts is quite flexible, and you can use that to enforce\natomicity. With the construction described above, you can either refund\ncooperatively (and collect evidence that refund has happened), or, if\nthat fails, go to court to enforce settlement there.\n\n\nCJP\n\n\nOp 12-02-18 om 10:23 schreef Christian Decker:\n\u003e CJP \u003ccjp at ultimatestunts.nl\u003e writes:\n\u003e\u003e Can you give a use case for this?\n\u003e\u003e\n\u003e\u003e Usually, especially in the common case that a payment is done in\n\u003e\u003e exchange for some non-cryptographic asset (e.g. physical goods), there\n\u003e\u003e already is some kind of trust between payer and payee. So, if a payment\n\u003e\u003e is split non-atomically into smaller transactions, and only a part\n\u003e\u003e succeeds, presumably they can cooperatively figure out some way to\n\u003e\u003e settle the situation.\n\u003e The scenario that is commonly used in these cases is a merchant that\n\u003e provides a signed invoice \"if you pay me X with payment_hash Y I will\n\u003e deliver Z\". Now the user performs the payment, learns the payment_key\n\u003e matching the payment_hash, but the merchant refuses to deliver, claiming\n\u003e it didn't get the payment. Now the user can go to a court, present the\n\u003e invoice signed by the merchant, and the proof-of-payment, and force the\n\u003e merchant to honor its commitment.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "94a68ba037fb627994f6744a03e0f2b5db948ea83b46e0571b17dcfd27528ba5564c2f47c51d3afa2a8340a9ee243ca65111a8cf46fa90830f310ef1b55f7ae1"
}