Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-30 📝 Original message: After listening to the ...
📅 Original date posted:2023-01-30
📝 Original message:
After listening to the optech space on the topic, thought it might be
worth having a second go at explaining the idea...
Alice is trying to pay Bob. Alice has an LSP, Louise. Bob has an LSP
Larry. Louise and Larry are online 24/7 but don't have access to Alice
and Bob's private keys. We want the payment flow to be something like:
1) Larry gets some setup info from Bob, Bob goes offline.
* Alice hears about Bob's address, and decides to pay Bob $50.
2) Alice coordinates a unique invoice id with Larry, which we'll call S.
3) Alice tells Louise that she's trying to pay Bob $50 for invoice S.
* Louise registers with Larry to be told when Bob is online.
* Alice goes offline.
* Bob goes online.
* Larry tells Louise that Bob is online.
4) Louise sends the payment to Bob conditional on S.
5) Bob accepts the payment.
* Louise claims the $50 from Alice and closes out the transaction.
6) Alice receives a receipt from Bob.
The goal of a receipt is that if two people want to pay Bob $50, they'll
be able to guarantee that (a) Bob was paid, rather than someone else; (b)
that the receipts are different (so Bob received $100 total, rather than
$50 going somewhere else and one of them just got a photocopied receipt);
and (c) after the fact they can prove that the receipt was theirs,
not someone else's. (a) and (b) prevent the funds getting misdirected;
(c) potentially allows you to use the receipt as evidence to a third
party if you paid for something in advance, then didn't receive it.
To get all those things, what we want is really more like a signature,
than just a hash/preimage. But PTLC preimages and schnorr signatures
aren't much different: with a PTLC preimage, you pay to point S and then
receive back the preimage s, where s*G = S. Meanwhile schnorr signatures
are made up of a number (s) and a point (R), which satisfy the equation:
s*G = R + H(R,P,m)*P
But, if you're willing to squint a bit, you can just wrap the whole
right side of the equation up as "S", and treat it as a PTLC.
(notation: I use capital letters to represent points, and lower case
letters to represent numbers; so if A is a point, a is it's discrete log,
and a*G = A)
To calculate S, you need to know three things: R, P and m -- P is just
the signer's public key, m is the message being signed, but "R" is the
public "nonce" part of the signature, that has to be chosen by the signer
(otherwise whoever does choose it can probably arrange to discover the
signer's private key after a signature or two).
So in that case, the protocol looks like:
Alice proposes that Bob signs a message, eg
m = "Alice paid me $50 -- Bob"
(perhaps this can be some standard nostr message, eg)
Bob chooses an R for this signature, and tells Alice what R is
Alice calculates "S"
Alice pays Bob $50 via a PTLC conditional on S
If Bob accepts the $50, Alice receives the preimage of S, ie s
Alice combines (R,s) and that is a Bob's signature on her message
Having Bob be offline with Alice only able to talk to his
not-fully-trusted representative Larry complicates things. Bob now can't
just choose a brand new R after already knowing Alice's message m, and
that introduces cryptographic attacks [0], where if Alice can request
nonces for many messages she may be able to find a lucky combination
of messages/nonces where she can combine the signatures Bob ends up
generating to steal Bob's private key.
[0] https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da
I *think* those attacks can be avoided by using the same musig2 approach
to generating nonces:
Bob prepares a nonce *pair* R1, R2
Alice chooses the message m
The nonce for the message m is calculated as H(R1,R2,m)*R1 + R2
Note that this doesn't allow you to safely reuse nonces -- if you have
three messages signed with the same R1/R2 pair, the schnorr signing
equation (s = r + H(R,P,m)*p) over each of the three messages gives you
three equations with just three unknowns (r1, r2, and the secret key
p), which you can use regular maths to solve, no fancy attacks needed.
(Presumably if you just reuse a pair twice you open yourself back up to
a Wagner attack)
So that adds up to:
1) Bob shares with Larry a bunch of (R1,R2) points that will form the
basis of his signature nonces. They can be constructed via a
(hardened) HD scheme so that Bob can easily regenerate them just
from an index, eg.
2) Alice obtains a unique (R1,R2) pair from Larry
Alice determines the message she wants Bob to sign (presumably Bob
provides a standard template, and Alice fills in her name and perhaps
what she's paying for) -- this is "m".
Alice calculates R from R1,R2,m; and S from R,P,m
3) Alice passes "m" and "S" onto Louise and starts the payment, locking
up her funds
4) Louise passes "m", "R1", "R2" onto Bob once he's online and sends
the payment to Bob.
5) Bob checks that R1/R2 were what he generated and haven't already
been used; Bob checks that "m" is something he's willing to sign;
Bob calculates s and S, and accepts the payment for S, provided it's
the correct amount as specified in "m", by revealing s.
6) Alice already calculated R and now receives s from Louise when
Louise claims her funds, and (R,s) is a BIP340 signature of m by
Bob, satisfying s*G = R + H(R,P,m)*P, and that signature serves as
her payment receipt from Bob.
Cheers,
aj
On Thu, Jan 26, 2023 at 11:04:12AM +1000, Anthony Towns wrote:
> 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
----- End forwarded message -----
📝 Original message:
After listening to the optech space on the topic, thought it might be
worth having a second go at explaining the idea...
Alice is trying to pay Bob. Alice has an LSP, Louise. Bob has an LSP
Larry. Louise and Larry are online 24/7 but don't have access to Alice
and Bob's private keys. We want the payment flow to be something like:
1) Larry gets some setup info from Bob, Bob goes offline.
* Alice hears about Bob's address, and decides to pay Bob $50.
2) Alice coordinates a unique invoice id with Larry, which we'll call S.
3) Alice tells Louise that she's trying to pay Bob $50 for invoice S.
* Louise registers with Larry to be told when Bob is online.
* Alice goes offline.
* Bob goes online.
* Larry tells Louise that Bob is online.
4) Louise sends the payment to Bob conditional on S.
5) Bob accepts the payment.
* Louise claims the $50 from Alice and closes out the transaction.
6) Alice receives a receipt from Bob.
The goal of a receipt is that if two people want to pay Bob $50, they'll
be able to guarantee that (a) Bob was paid, rather than someone else; (b)
that the receipts are different (so Bob received $100 total, rather than
$50 going somewhere else and one of them just got a photocopied receipt);
and (c) after the fact they can prove that the receipt was theirs,
not someone else's. (a) and (b) prevent the funds getting misdirected;
(c) potentially allows you to use the receipt as evidence to a third
party if you paid for something in advance, then didn't receive it.
To get all those things, what we want is really more like a signature,
than just a hash/preimage. But PTLC preimages and schnorr signatures
aren't much different: with a PTLC preimage, you pay to point S and then
receive back the preimage s, where s*G = S. Meanwhile schnorr signatures
are made up of a number (s) and a point (R), which satisfy the equation:
s*G = R + H(R,P,m)*P
But, if you're willing to squint a bit, you can just wrap the whole
right side of the equation up as "S", and treat it as a PTLC.
(notation: I use capital letters to represent points, and lower case
letters to represent numbers; so if A is a point, a is it's discrete log,
and a*G = A)
To calculate S, you need to know three things: R, P and m -- P is just
the signer's public key, m is the message being signed, but "R" is the
public "nonce" part of the signature, that has to be chosen by the signer
(otherwise whoever does choose it can probably arrange to discover the
signer's private key after a signature or two).
So in that case, the protocol looks like:
Alice proposes that Bob signs a message, eg
m = "Alice paid me $50 -- Bob"
(perhaps this can be some standard nostr message, eg)
Bob chooses an R for this signature, and tells Alice what R is
Alice calculates "S"
Alice pays Bob $50 via a PTLC conditional on S
If Bob accepts the $50, Alice receives the preimage of S, ie s
Alice combines (R,s) and that is a Bob's signature on her message
Having Bob be offline with Alice only able to talk to his
not-fully-trusted representative Larry complicates things. Bob now can't
just choose a brand new R after already knowing Alice's message m, and
that introduces cryptographic attacks [0], where if Alice can request
nonces for many messages she may be able to find a lucky combination
of messages/nonces where she can combine the signatures Bob ends up
generating to steal Bob's private key.
[0] https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da
I *think* those attacks can be avoided by using the same musig2 approach
to generating nonces:
Bob prepares a nonce *pair* R1, R2
Alice chooses the message m
The nonce for the message m is calculated as H(R1,R2,m)*R1 + R2
Note that this doesn't allow you to safely reuse nonces -- if you have
three messages signed with the same R1/R2 pair, the schnorr signing
equation (s = r + H(R,P,m)*p) over each of the three messages gives you
three equations with just three unknowns (r1, r2, and the secret key
p), which you can use regular maths to solve, no fancy attacks needed.
(Presumably if you just reuse a pair twice you open yourself back up to
a Wagner attack)
So that adds up to:
1) Bob shares with Larry a bunch of (R1,R2) points that will form the
basis of his signature nonces. They can be constructed via a
(hardened) HD scheme so that Bob can easily regenerate them just
from an index, eg.
2) Alice obtains a unique (R1,R2) pair from Larry
Alice determines the message she wants Bob to sign (presumably Bob
provides a standard template, and Alice fills in her name and perhaps
what she's paying for) -- this is "m".
Alice calculates R from R1,R2,m; and S from R,P,m
3) Alice passes "m" and "S" onto Louise and starts the payment, locking
up her funds
4) Louise passes "m", "R1", "R2" onto Bob once he's online and sends
the payment to Bob.
5) Bob checks that R1/R2 were what he generated and haven't already
been used; Bob checks that "m" is something he's willing to sign;
Bob calculates s and S, and accepts the payment for S, provided it's
the correct amount as specified in "m", by revealing s.
6) Alice already calculated R and now receives s from Louise when
Louise claims her funds, and (R,s) is a BIP340 signature of m by
Bob, satisfying s*G = R + H(R,P,m)*P, and that signature serves as
her payment receipt from Bob.
Cheers,
aj
On Thu, Jan 26, 2023 at 11:04:12AM +1000, Anthony Towns wrote:
> 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
----- End forwarded message -----