From aj at erisian.com.au  Thu Jan 26 01:04:12 2023
From: aj at erisian.com.au (Anthony Towns)
Date: Thu, 26 Jan 2023 11:04:12 +1000
Subject: [Lightning-dev] Async payments proof-of-payment: a wishlist for
 researchers
In-Reply-To: <U5s6sP-LNSuz3BeEEcGG3N5pqiOK3TkbfMpz5Y65LC1zWg4auTVaMh8z4e5yR6feEK5OJEge4pMTayfTpEGMHNivkOSwWNE8Q796OwqNDZM=@protonmail.com>
References: <U5s6sP-LNSuz3BeEEcGG3N5pqiOK3TkbfMpz5Y65LC1zWg4auTVaMh8z4e5yR6feEK5OJEge4pMTayfTpEGMHNivkOSwWNE8Q796OwqNDZM=@protonmail.com>
Message-ID: <Y9HRjPv24KMndFaV@erisian.com.au>

On Tue, Jan 10, 2023 at 07:41:09PM +0000, vwallace via Lightning-dev wrote:
> The open research question relates to how the sender will get an invoice from the receiver, given that they are offline at sending-time.

Assuming the overall process is:

 * Alice sends a payment to Bob, who has provided a reusable address
   AddrBob
 * Bob is offline at the time the payment is sent, but his semi-trusted
   LSP Larry is online
 * Alice is willing/able to do bidirectional communication with Larry
 * The payment does not complete until Bob is online (at which point
   Alice may be offline)

I think in this case you want to aim for the receipt to be a BIP340
signature of the message "Alice has paid me $50 -- signed Bob".

Given Bob's public signature nonce, R, Alice (and Larry) can calculate
S = R + H(R,P,m)*P (m is the receipt message, P is Bob's public key),
and then Alice can send a PTLC conditional on revealing the log of S, ie
s where s*G=S; and at that point (s, R) is a valid signature by Bob of a
message confirming payment to Bob, which then serves as the final receipt.

However for this to work, Alice needs to discover "R" while Bob is
offline. I think this is only doable if Bob pre-generates a set of
nonces and shares the public part with Larry, who can then share them
with potential payers.  I think to avoid attacks via Wagner's algorithm,
you probably need to do a similar setup as musig2 does, ie share (R1,R2)
pairs, and calculate R = H(P,R1,R2,m)*R1+R2.

So a setup like:

  Alice gets AddrBob. Decodes Bob's pubkey, Larry's pubkey, and the
  route to Larry.

  Alice -> Larry: "Hi, I want to send Bob $50, and get a receipt"
  Larry -> Alice: "The nonce for that will be R"
  Alice: calculates m = "Hash("Alice paid Bob $50"), S = R+H(R,P,m)*P
  Alice -> Larry(for Bob): PTLC[$50, S]

  Larry -> Bob: PTLC[$50, S]
                Alice wants to pay you $50, using nonce pair #12345
  Bob: verifies nonce #12345 has not been previously used, calculates R,
       calculates m, calculates s, and checks that s*G = S, checks
       there's a $50 PTLC conditional on S waiting for confirmation.
  Bob -> Alice: claims $50 from PTLC by revealing s

  Alice: receives s; (R,s) serves as Bob's signature confirming payment

seems plausible?

Every "S" here commits to a value chosen by the sender (ie, their
"identity"), so there's no way for Larry to get two different payers
to use the same S. Using the same nonce twice will just mean Bob has to
reject the payment (and find a new LSP).

It may make sense to require Alice to make a micropayment to Larry in
order to claim a nonce. You'd want a standard template for "m" so that
it's easy to generate and parse consistently, of course.

I think you could even have separate LSPs if you wanted: one to issue
nonces while you're offline, and the other to actually hold onto incoming
PTLCs while you're offline.

FWIW, some previous discussion, which didn't focus on offline recipients:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001034.html

https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001490.html

Cheers,
aj