📅 Original date posted:2018-02-13
📝 Original message:
Hi everyone,
I've seen some discussions over losing proofs of payment in the AMP setting,
and wanted to address some lingering concerns I have regarding the
soundness of using the current invoicing system to prove payments.
In general, I think we are ascribing too much weight to simply having a
preimage and BOLT 11 invoice. The structure of non-interactive payments
definitely poses some interesting challenges in adapting the existing
invoicing
scheme. However, I believe there exist stronger and better means of doing
proofs of payment, and would prefer not to tie our hands by assuming
this is the best way to approach the problem.
IMHO, the current signed invoice + preimage is a very weak proof of payment.
It's the hash equivalent to proving you own a public key by publishing the
secret key. There is an assumption that the only way someone could get that
preimage is by having made a payment, but this assumption is broken most
directly by the proving mechanism. Similarly, any intermediary who acquires
an invoice with the appropriate hash could also make this claim since they
also have the preimage.
Further, I think it's a mistake to conflate
1) me being able to present a valid preimage/invoice pair, with
2) me having received the correct preimage in response to an onion packet
that I personally crafted for the receiving node in the invoice.
The main issue is that the proof does not bind a specific sender,
making statement 1 producible by multiple individuals. I think it would be
potentially worthwhile to explore proofs of stronger statements, such as 2,
that could utilize the ephemeral keys in the onion packets, or even the
onion as a witness, which is more rigidly coupled to having actually
completed a payment.
Without any modification to the spec, we can always use something like
ZKBoo to prove (w/o trusted setup) knowledge of a preimage without
totally revealing it to the verifier. This isn't perfect, but at least
gives the
sender the option to prove the statement without necessarily giving up
the preimage.
TL;DR: I'm not convinced the signed invoice + hash is really a good
yardstick
by which to measure provability, and I think doing some research into proofs
of payment on stronger statements would be incredibly valuable. Therefore,
I'm not sure if AMPs really lose this, so much as force us to reconsider
what it actually requires to soundly prove a payment to an external
verifier.
Best,
Conner
On Mon, Feb 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Christian and Corne,
>
> Another idea to consider, is techniques like ZKCP and ZKCSP, which provide
> atomic access to information in exchange for monetary compensation.
> Ensuring atomicity of the exchange can be done by providing the information
> encrypted, a hash of the encryption key, and proofs that the encrypted data
> is the one desired and that the data was encrypted with the given key; the
> proof-of-payment is the encryption key, and possession of the encryption
> key is sufficient to gain access to the information, with no need to bring
> in legal structures.
>
> (admittedly, ZKCP and ZKCSP are dependent on new cryptography...)
>
> (also, AMP currently cannot provide a proof-of-payment, unlike current
> payment routing that has proof-of-payment, but that is an eventual design
> goal that would enable use of ZKC(S)P on-Lightning, assuming we eventually
> find out that zk-SNARKs and so on are something we can trust)
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
>
> -------- Original Message --------
> On February 13, 2018 2:05 AM, Christian Decker <
> decker.christian at gmail.com> wrote:
>
> >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
> >>
> >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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180213/361f3c65/attachment.html>;
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:49:05
in reply to nevent1q…hu6m
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:49:05Event JSON
{
"id": "c306be45d7031f02213d4f67fa1c8d18cfb21f63514ac6196ed14443bbe14f67",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686314945,
"kind": 1,
"tags": [
[
"e",
"51bc92b7fa9a7d9c09bb73c2362ca09a737a241a77a68cd95503c148136969eb",
"",
"root"
],
[
"e",
"8107bcd894d787f7afcdcc5b8bcaa32d0b06f6f0fbab4661d0f7e76e4c166923",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-02-13\n📝 Original message:\nHi everyone,\n\nI've seen some discussions over losing proofs of payment in the AMP setting,\nand wanted to address some lingering concerns I have regarding the\nsoundness of using the current invoicing system to prove payments.\n\nIn general, I think we are ascribing too much weight to simply having a\npreimage and BOLT 11 invoice. The structure of non-interactive payments\ndefinitely poses some interesting challenges in adapting the existing\ninvoicing\nscheme. However, I believe there exist stronger and better means of doing\nproofs of payment, and would prefer not to tie our hands by assuming\nthis is the best way to approach the problem.\n\nIMHO, the current signed invoice + preimage is a very weak proof of payment.\nIt's the hash equivalent to proving you own a public key by publishing the\nsecret key. There is an assumption that the only way someone could get that\npreimage is by having made a payment, but this assumption is broken most\ndirectly by the proving mechanism. Similarly, any intermediary who acquires\nan invoice with the appropriate hash could also make this claim since they\nalso have the preimage.\n\nFurther, I think it's a mistake to conflate\n 1) me being able to present a valid preimage/invoice pair, with\n 2) me having received the correct preimage in response to an onion packet\n that I personally crafted for the receiving node in the invoice.\n\nThe main issue is that the proof does not bind a specific sender,\nmaking statement 1 producible by multiple individuals. I think it would be\npotentially worthwhile to explore proofs of stronger statements, such as 2,\nthat could utilize the ephemeral keys in the onion packets, or even the\nonion as a witness, which is more rigidly coupled to having actually\ncompleted a payment.\n\nWithout any modification to the spec, we can always use something like\nZKBoo to prove (w/o trusted setup) knowledge of a preimage without\ntotally revealing it to the verifier. This isn't perfect, but at least\ngives the\nsender the option to prove the statement without necessarily giving up\nthe preimage.\n\nTL;DR: I'm not convinced the signed invoice + hash is really a good\nyardstick\nby which to measure provability, and I think doing some research into proofs\nof payment on stronger statements would be incredibly valuable. Therefore,\nI'm not sure if AMPs really lose this, so much as force us to reconsider\nwhat it actually requires to soundly prove a payment to an external\nverifier.\n\nBest,\nConner\n\nOn Mon, Feb 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Christian and Corne,\n\u003e\n\u003e Another idea to consider, is techniques like ZKCP and ZKCSP, which provide\n\u003e atomic access to information in exchange for monetary compensation.\n\u003e Ensuring atomicity of the exchange can be done by providing the information\n\u003e encrypted, a hash of the encryption key, and proofs that the encrypted data\n\u003e is the one desired and that the data was encrypted with the given key; the\n\u003e proof-of-payment is the encryption key, and possession of the encryption\n\u003e key is sufficient to gain access to the information, with no need to bring\n\u003e in legal structures.\n\u003e\n\u003e (admittedly, ZKCP and ZKCSP are dependent on new cryptography...)\n\u003e\n\u003e (also, AMP currently cannot provide a proof-of-payment, unlike current\n\u003e payment routing that has proof-of-payment, but that is an eventual design\n\u003e goal that would enable use of ZKC(S)P on-Lightning, assuming we eventually\n\u003e find out that zk-SNARKs and so on are something we can trust)\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e \n\u003e Sent with ProtonMail Secure Email.\n\u003e \n\u003e\n\u003e -------- Original Message --------\n\u003e On February 13, 2018 2:05 AM, Christian Decker \u003c\n\u003e decker.christian at gmail.com\u003e wrote:\n\u003e\n\u003e \u003eHonestly I don't get why we are complicating this so much. We have a\n\u003e \u003e system that allows atomic multipath payments using a single secret, and\n\u003e \u003e future decorrelation mechanisms allow us to vary the secret in such a\n\u003e \u003e way that multiple paths cannot be collated, why introduce a whole set of\n\u003e \u003e problems by giving away the atomicity? The same goes for the overpaying\n\u003e \u003e and trusting the recipient to only claim the owed amount, there is no\n\u003e \u003e need for this. Just pay the exact amount, by deriving secrets from the\n\u003e \u003e main secret and make the derivation reproducible by intermediate hops.\n\u003e \u003e\n\u003e \u003e Having proof-of-payment be presentable in a court is a nice feature, but\n\u003e \u003e it doesn't mean we need to abandon all guarantees we have worked so hard\n\u003e \u003e to establish in LN.\n\u003e \u003e\n\u003e \u003e Corné Plooy via Lightning-dev lightning-dev at lists.linuxfoundation.org\n\u003e \u003ewrites:\n\u003e \u003e\n\u003e \u003e\u003eI was thinking that, for that use case, a different signed invoice could\n\u003e \u003e\u003e be formulated, stating\n\u003e \u003e\u003e - several payment hashes with their corresponding amounts\n\u003e \u003e\u003e\n\u003e \u003e\u003e - the obligation of signer to deliver Z if all corresponding payment\n\u003e \u003e\u003e keys are shown\n\u003e \u003e\u003e\n\u003e \u003e\u003e - some terms to handle the case where only a part of the payments was\n\u003e \u003e\u003e successful, e.g. an obligation to refund\n\u003e \u003e\u003eThe third item is a bit problematic: in order to distinguish this case\n\u003e \u003e\u003e from a complete success, the payee would have to prove absence of\n\u003e \u003e\u003e successful transactions, which is hard. Absence of successful\n\u003e \u003e\u003e transactions can only be declared by the payer, so in order to reliably\n\u003e \u003e\u003e settle without going to court first, the payer should sign a\n\u003e \u003e\u003e declaration stating that certain transactions were canceled and that the\n\u003e \u003e\u003e other ones should be refunded. This can be another invoice.\n\u003e \u003e\u003eSo, the original invoice states:\n\u003e \u003e\u003e - several payment hashes with their corresponding amounts\n\u003e \u003e\u003e\n\u003e \u003e\u003e - if all corresponding payment keys are shown: the obligation of \u003cpayee\u003e\n\u003e \u003e\u003e to deliver Z, UNLESS stated otherwise by an invoice signed by \u003cpayer\u003e\n\u003e \u003e\u003e-- signed by \u003cpayee\u003e\n\u003e \u003e\u003eBut if a payment partially fails, it can be refunded cooperatively with\n\u003e \u003e\u003e an invoice created by payer:\n\u003e \u003e\u003e - declares which of the original payments were successful (with payment\n\u003e \u003e\u003e keys) and which were not\n\u003e \u003e\u003e\n\u003e \u003e\u003e - replaces the obligation of \u003cpayee\u003e to deliver Z with an obligation to\n\u003e \u003e\u003e refund the successful transactions\n\u003e \u003e\u003e\n\u003e \u003e\u003e - several payment hashes with their corresponding amounts\n\u003e \u003e\u003e\n\u003e \u003e\u003e - if all corresponding payment keys are shown: cancel the obligation of\n\u003e \u003e\u003e \u003cpayee\u003e to refund\n\u003e \u003e\u003e-- signed by \u003cpayer\u003e\n\u003e \u003e\u003eMaybe this can be repeated iteratively if necessary; hopefully the\n\u003e \u003e\u003e not-yet-settled amount will converge to zero.\n\u003e \u003e\u003eImportant advantage: this only requires changes to the invoice format,\n\u003e \u003e\u003e not to the network protocol.\n\u003e \u003e\u003eThe point is: in this use case, the court is apparently the final point\n\u003e \u003e\u003e of settlement for invoices, just like the blockchain is for the other\n\u003e \u003e\u003e channels in the route. IANAL, but I think the \"scripting language\"\n\u003e \u003e\u003e accepted by courts is quite flexible, and you can use that to enforce\n\u003e \u003e\u003e atomicity. With the construction described above, you can either refund\n\u003e \u003e\u003e cooperatively (and collect evidence that refund has happened), or, if\n\u003e \u003e\u003e that fails, go to court to enforce settlement there.\n\u003e \u003e\u003eCJP\n\u003e \u003e\u003eOp 12-02-18 om 10:23 schreef Christian Decker:\n\u003e \u003e\u003e\u003eCJP cjp at ultimatestunts.nl writes:\n\u003e \u003e\u003e\u003e\u003eCan you give a use case for this?\n\u003e \u003e\u003e\u003e\u003eUsually, especially in the common case that a payment is done in\n\u003e \u003e\u003e\u003e\u003e exchange for some non-cryptographic asset (e.g. physical goods), there\n\u003e \u003e\u003e\u003e\u003e already is some kind of trust between payer and payee. So, if a\n\u003e payment\n\u003e \u003e\u003e\u003e\u003e is split non-atomically into smaller transactions, and only a part\n\u003e \u003e\u003e\u003e\u003e succeeds, presumably they can cooperatively figure out some way to\n\u003e \u003e\u003e\u003e\u003e settle the situation.\n\u003e \u003e\u003e\u003e\u003e The scenario that is commonly used in these cases is a merchant that\n\u003e \u003e\u003e\u003e\u003e provides a signed invoice \"if you pay me X with payment_hash Y I will\n\u003e \u003e\u003e\u003e\u003e deliver Z\". Now the user performs the payment, learns the payment_key\n\u003e \u003e\u003e\u003e\u003e matching the payment_hash, but the merchant refuses to deliver,\n\u003e claiming\n\u003e \u003e\u003e\u003e\u003e it didn't get the payment. Now the user can go to a court, present the\n\u003e \u003e\u003e\u003e\u003e invoice signed by the merchant, and the proof-of-payment, and force\n\u003e the\n\u003e \u003e\u003e\u003e\u003e merchant to honor its commitment.\n\u003e \u003e\u003e\u003e\u003e\n\u003e \u003e\u003e\u003eLightning-dev mailing list\n\u003e \u003e\u003e\u003eLightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003eLightning-dev mailing list\n\u003e \u003e\u003eLightning-dev at lists.linuxfoundation.org\n\u003e \u003e\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\u003e\n\u003e \u003eLightning-dev mailing list\n\u003e \u003eLightning-dev at lists.linuxfoundation.org\n\u003e \u003ehttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180213/361f3c65/attachment.html\u003e",
"sig": "5b42dd67e7940f4abe0bb7dd3dc1ed8e6b8dc40e9a499fcf96202bedb632a0c90d43375994cb71fb384799970c9d415f2017ff36399db6ba15913f665f16e578"
}