Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-05 📝 Original message: On Sun, Nov 04, 2018 at ...
📅 Original date posted:2018-11-05
📝 Original message:
On Sun, Nov 04, 2018 at 08:04:20PM +1030, Rusty Russell wrote:
> >> > - just send multiple payments with the same hash:
> >> > works with sha256
> >> > privacy not improved much (some intermediary nodes no longer know
> >> > full invoice value)
> >> > can claim partial payments as soon as they arrive
> >> > accepting any partial payment provides proof-of-payment
> >> Interestingly, if vendor takes part payment, rest can be stolen by
> >> intermediaries.
> > Or you could just see a $5 bill, send $0.50 through, and wait to see
> > if the take the partial payment immediately before even trying the
> > remaining $4.50.
> Sure, that's true today, too?
Yeah, exactly. So to get correct behaviour vendors/payees need to check
the HTLC amount matches what they expect already... They could just
automatically pause instead of rejecting here to see if more payments
come through in the next n seconds via (presumably) different paths,
with no extra message bit required. (A bit in the invoice indicating
you'll do this would probably be useful though)
> > Vendor -> *: "I sell widgets for 0.01 BTC, my pubkey is P"
> > Customer -> Vendor: "I want to buy a widget"
> > Vendor -> Customer: "Here's an R value"
> > Customer: calculates S = R + H(P,R,"send $me a widget at $address")*P
> > Customer -> Vendor: "here's 0.01 BTC for s corresponding to S, my
> > details are R, $me, $address"
> > Vendor: looks up r for R=r*G, calculates s = r + H(P,R,"send $me a
> > widget at $address")*p, checks S=s*G
> > Vendor -> Customer: <accepts payment, revealing s>
> >
> > Customer -> Court: reveals the invoice ("send $me a widget...") and the
> > signature by Vendor's pubkey P, (s,R)
> >
> > I think the way to do secp256k1 AMP with that is that when sending
> > through the payment is for the customer to send three payments to the
> > Vendor conditional on preimages for A,B,C calculated as:
> >
> > A = S + H(1,secret)*G
> > B = S + H(2,secret)*G
> > C = S + H(3,secret)*G
> Note: I prefer the construction H(<secret>,<part-of-secret-in-that-payment>)
> which doesn't require an explicit order.
Yes, you're quite right.
> I'm not sure I see the benefit over just treating them independently,
> so I also think we should defer.
If you've got a path that merges, then goes for a few hops, you'd save
on the fee_base_msat fees, and allow the merged hops to have smaller
commitment transactions. Kinda neat, but the complexity in doing the
onion stuff means it definitely makes sense to defer IMO.
> >> [1] If we're not careful we're going to implement HORNET so we can pass
> >> arbitrary messages around, which means we want to start charging for
> >> them to prevent spam, which means we reopen the pre-payment debate, and
> >> need reliable error messages...
> > Could leave the interactivity to the "web store" layer, eg have a BOLT
> > 11 v1.1 "offer" include a url for the website where you go an enter your
> > name and address and whatever other info they need, and get a personalised
> > BOLT 11 v1.1 "invoice" back with payment-hash/nonce/signature/whatever?
> I think that's out-of-scope, and I generally dislike including a URL
> since it's an unsigned externality and in practice has horrible privacy
> properties.
Maybe... I'm not sure that it'll make sense to try to negotiate postage
and handling fees over lightning, rather than over https, though?
BTW, reviewing contract law terminology, I think the way lawyers would
call it is:
"invitation to treat" -- advertising that you'll sell widgets for $x
"offer" -- I'll pay you $3x for delivery of 3 widgets to my address
"acceptance" -- you agree, take my $3x and give me a receipt
"consideration" -- you get my $3x, I get 3 widgets
So it might be better to have the terms be "advertisment", "invoice",
"receipt", because the "advertisement" isn't quite an offer in
contract-law terms. In any event, I think that would mean the BOLT-11
terms and lightning payment process would map nicely into contract law
101, which seems helpful.
Oh! Post-Schnorr I think there's a good reason for the payee to
include their own crypto key in the invoice; so you can generate an
scriptless-script address for an on-chain fallback payment directly
between the payer/payee that reveals proof-of-payment on acceptance
(and allow refund on timeout via taproot I guess). At least, I think
all that might be theoretically feasible.
Cheers,
aj
📝 Original message:
On Sun, Nov 04, 2018 at 08:04:20PM +1030, Rusty Russell wrote:
> >> > - just send multiple payments with the same hash:
> >> > works with sha256
> >> > privacy not improved much (some intermediary nodes no longer know
> >> > full invoice value)
> >> > can claim partial payments as soon as they arrive
> >> > accepting any partial payment provides proof-of-payment
> >> Interestingly, if vendor takes part payment, rest can be stolen by
> >> intermediaries.
> > Or you could just see a $5 bill, send $0.50 through, and wait to see
> > if the take the partial payment immediately before even trying the
> > remaining $4.50.
> Sure, that's true today, too?
Yeah, exactly. So to get correct behaviour vendors/payees need to check
the HTLC amount matches what they expect already... They could just
automatically pause instead of rejecting here to see if more payments
come through in the next n seconds via (presumably) different paths,
with no extra message bit required. (A bit in the invoice indicating
you'll do this would probably be useful though)
> > Vendor -> *: "I sell widgets for 0.01 BTC, my pubkey is P"
> > Customer -> Vendor: "I want to buy a widget"
> > Vendor -> Customer: "Here's an R value"
> > Customer: calculates S = R + H(P,R,"send $me a widget at $address")*P
> > Customer -> Vendor: "here's 0.01 BTC for s corresponding to S, my
> > details are R, $me, $address"
> > Vendor: looks up r for R=r*G, calculates s = r + H(P,R,"send $me a
> > widget at $address")*p, checks S=s*G
> > Vendor -> Customer: <accepts payment, revealing s>
> >
> > Customer -> Court: reveals the invoice ("send $me a widget...") and the
> > signature by Vendor's pubkey P, (s,R)
> >
> > I think the way to do secp256k1 AMP with that is that when sending
> > through the payment is for the customer to send three payments to the
> > Vendor conditional on preimages for A,B,C calculated as:
> >
> > A = S + H(1,secret)*G
> > B = S + H(2,secret)*G
> > C = S + H(3,secret)*G
> Note: I prefer the construction H(<secret>,<part-of-secret-in-that-payment>)
> which doesn't require an explicit order.
Yes, you're quite right.
> I'm not sure I see the benefit over just treating them independently,
> so I also think we should defer.
If you've got a path that merges, then goes for a few hops, you'd save
on the fee_base_msat fees, and allow the merged hops to have smaller
commitment transactions. Kinda neat, but the complexity in doing the
onion stuff means it definitely makes sense to defer IMO.
> >> [1] If we're not careful we're going to implement HORNET so we can pass
> >> arbitrary messages around, which means we want to start charging for
> >> them to prevent spam, which means we reopen the pre-payment debate, and
> >> need reliable error messages...
> > Could leave the interactivity to the "web store" layer, eg have a BOLT
> > 11 v1.1 "offer" include a url for the website where you go an enter your
> > name and address and whatever other info they need, and get a personalised
> > BOLT 11 v1.1 "invoice" back with payment-hash/nonce/signature/whatever?
> I think that's out-of-scope, and I generally dislike including a URL
> since it's an unsigned externality and in practice has horrible privacy
> properties.
Maybe... I'm not sure that it'll make sense to try to negotiate postage
and handling fees over lightning, rather than over https, though?
BTW, reviewing contract law terminology, I think the way lawyers would
call it is:
"invitation to treat" -- advertising that you'll sell widgets for $x
"offer" -- I'll pay you $3x for delivery of 3 widgets to my address
"acceptance" -- you agree, take my $3x and give me a receipt
"consideration" -- you get my $3x, I get 3 widgets
So it might be better to have the terms be "advertisment", "invoice",
"receipt", because the "advertisement" isn't quite an offer in
contract-law terms. In any event, I think that would mean the BOLT-11
terms and lightning payment process would map nicely into contract law
101, which seems helpful.
Oh! Post-Schnorr I think there's a good reason for the payee to
include their own crypto key in the invoice; so you can generate an
scriptless-script address for an on-chain fallback payment directly
between the payer/payee that reveals proof-of-payment on acceptance
(and allow refund on timeout via taproot I guess). At least, I think
all that might be theoretically feasible.
Cheers,
aj