📅 Original date posted:2018-02-12
📝 Original message:
Honestly I don't get why we are complicating this so much. We have a
system that allows atomic multipath payments using a single secret, and
future decorrelation mechanisms allow us to vary the secret in such a
way that multiple paths cannot be collated, why introduce a whole set of
problems by giving away the atomicity? The same goes for the overpaying
and trusting the recipient to only claim the owed amount, there is no
need for this. Just pay the exact amount, by deriving secrets from the
main secret and make the derivation reproducible by intermediate hops.
Having proof-of-payment be presentable in a court is a nice feature, but
it doesn't mean we need to abandon all guarantees we have worked so hard
to establish in LN.
Corné Plooy via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> 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
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:49:04
in reply to nevent1q…v6j8
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:49:04Event JSON
{
"id": "0404ef6f2ef2efd06aa42c142a37d04f70f97a9089c5c2a61fbb12ecb68d31c6",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314944,
"kind": 1,
"tags": [
[
"e",
"51bc92b7fa9a7d9c09bb73c2362ca09a737a241a77a68cd95503c148136969eb",
"",
"root"
],
[
"e",
"dbc04f40badd4023145756290bb26d5977eb184943ee10e96a6d0143bfa681f1",
"",
"reply"
],
[
"p",
"f928c1a284fddb630ed23aab2bfe69811423a59f41dd8c3e40c57b916fbadf65"
]
],
"content": "📅 Original date posted:2018-02-12\n📝 Original message:\nHonestly I don't get why we are complicating this so much. We have a\nsystem that allows atomic multipath payments using a single secret, and\nfuture decorrelation mechanisms allow us to vary the secret in such a\nway that multiple paths cannot be collated, why introduce a whole set of\nproblems by giving away the atomicity? The same goes for the overpaying\nand trusting the recipient to only claim the owed amount, there is no\nneed for this. Just pay the exact amount, by deriving secrets from the\nmain secret and make the derivation reproducible by intermediate hops.\n\nHaving proof-of-payment be presentable in a court is a nice feature, but\nit doesn't mean we need to abandon all guarantees we have worked so hard\nto establish in LN.\n\nCorné Plooy via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nwrites:\n\n\u003e I was thinking that, for that use case, a different signed invoice could\n\u003e be formulated, stating\n\u003e\n\u003e * several payment hashes with their corresponding amounts\n\u003e\n\u003e * the obligation of signer to deliver Z if all corresponding payment\n\u003e keys are shown\n\u003e\n\u003e * some terms to handle the case where only a part of the payments was\n\u003e successful, e.g. an obligation to refund\n\u003e\n\u003e\n\u003e The third item is a bit problematic: in order to distinguish this case\n\u003e from a complete success, the payee would have to prove *absence* of\n\u003e successful transactions, which is hard. Absence of successful\n\u003e transactions can only be declared by the payer, so in order to reliably\n\u003e settle *without* going to court first, the payer should sign a\n\u003e declaration stating that certain transactions were canceled and that the\n\u003e other ones should be refunded. This can be another invoice.\n\u003e\n\u003e\n\u003e So, the original invoice states:\n\u003e\n\u003e * several payment hashes with their corresponding amounts\n\u003e\n\u003e * if all corresponding payment keys are shown: the obligation of \u003cpayee\u003e\n\u003e to deliver Z, UNLESS stated otherwise by an invoice signed by \u003cpayer\u003e\n\u003e\n\u003e -- signed by \u003cpayee\u003e\n\u003e\n\u003e\n\u003e But if a payment partially fails, it can be refunded cooperatively with\n\u003e an invoice created by payer:\n\u003e\n\u003e * declares which of the original payments were successful (with payment\n\u003e keys) and which were not\n\u003e\n\u003e * replaces the obligation of \u003cpayee\u003e to deliver Z with an obligation to\n\u003e refund the successful transactions\n\u003e\n\u003e * several payment hashes with their corresponding amounts\n\u003e\n\u003e * if all corresponding payment keys are shown: cancel the obligation of\n\u003e \u003cpayee\u003e to refund\n\u003e\n\u003e -- signed by \u003cpayer\u003e\n\u003e\n\u003e\n\u003e Maybe this can be repeated iteratively if necessary; hopefully the\n\u003e not-yet-settled amount will converge to zero.\n\u003e\n\u003e\n\u003e Important advantage: this only requires changes to the invoice format,\n\u003e not to the network protocol.\n\u003e\n\u003e\n\u003e The point is: in this use case, the court is apparently the final point\n\u003e of settlement for invoices, just like the blockchain is for the other\n\u003e channels in the route. IANAL, but I think the \"scripting language\"\n\u003e accepted by courts is quite flexible, and you can use that to enforce\n\u003e atomicity. With the construction described above, you can either refund\n\u003e cooperatively (and collect evidence that refund has happened), or, if\n\u003e that fails, go to court to enforce settlement there.\n\u003e\n\u003e\n\u003e CJP\n\u003e\n\u003e\n\u003e Op 12-02-18 om 10:23 schreef Christian Decker:\n\u003e\u003e CJP \u003ccjp at ultimatestunts.nl\u003e writes:\n\u003e\u003e\u003e Can you give a use case for this?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Usually, especially in the common case that a payment is done in\n\u003e\u003e\u003e exchange for some non-cryptographic asset (e.g. physical goods), there\n\u003e\u003e\u003e already is some kind of trust between payer and payee. So, if a payment\n\u003e\u003e\u003e is split non-atomically into smaller transactions, and only a part\n\u003e\u003e\u003e succeeds, presumably they can cooperatively figure out some way to\n\u003e\u003e\u003e settle the situation.\n\u003e\u003e The scenario that is commonly used in these cases is a merchant that\n\u003e\u003e provides a signed invoice \"if you pay me X with payment_hash Y I will\n\u003e\u003e deliver Z\". Now the user performs the payment, learns the payment_key\n\u003e\u003e matching the payment_hash, but the merchant refuses to deliver, claiming\n\u003e\u003e it didn't get the payment. Now the user can go to a court, present the\n\u003e\u003e invoice signed by the merchant, and the proof-of-payment, and force the\n\u003e\u003e merchant to honor its commitment.\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\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": "ad1398093fceee2fe9962c7dfcd78a181db8aadbdd49f2f57c88f52161ca32d389fa15620824028c9397ff69bd0184549c645fee8733264e381de78bc681e30b"
}