On 09/03/2017 08:34 PM, Rusty Russell wrote:
Andy Schroder <[email protected]> writes:
Hello,
Yes, it seems as though high frequency payments are not a reality. For
high value products that are delivered quickly, "micro" payments are not
even possible. With my fuel delivery system, the smallest volume of
product that could be individually payed for would be on the order of a
hundred mL. If I were to implement paying by the 100mL, is there any
protocol for doing repeated payments? Do you have to request a new
payment request, or can you just send more to the same payment request?
Not currently, no: paying the same payment request twice is an
invitation for anyone in the middle to just take your funds!
Thanks for the clarification on this. So, basically, donations with
lightening work a lot different from with blockchain donation
(static/reused) addresses because they can't be re-used? If so, that's
fine. I always though static donation addresses were a cool idea, but at
the same time are a huge privacy problem for both parties. Might be
worth pointing this out in the BIP for newcomers.
With 1.1 we're looking at changing the way payment hashes work so this
will be possible (kind of like bip32, except for lightning).
That would definitely help.
Regarding the payment route going down, if you can re-use the same
payment request, when you say *during* a payment, do you mean when you
are actually sending the payment (I think this is probably it), or
everything related to that payment request (I don't think this is it)?
It seems like this could definitely be a problem for lower value
products that are delivered slowly over long periods of time, such as
water, natural gas, electricity, internet, a parking meter, or some kind
of digital content.
No, it's only during the actualy payment. Which looks like:
A: Hi B, I'll pay you $1 for preimage of hash X.
B: Hi C, I'll pay you $0.99 for preimage of hash X.
C: Hi D, I'll pay you $0.98 for preimage of hash X.
D: Thanks C, here's the preimage.
C: Thanks B, here's the preimage.
B: Thanks A, here's the preimage.
Now, if B or C go down after receiving the offer but before either
failing or returning the preimage, A has to wait, unsure if they'll try
to redeem the offer or not. (If B or C are simply offline, A or B
simply fail and A gets to try again on a different route).
Are there any security holes where B or C can receive the offer, but
pretend they don't and then the payment gets re-routed some other way?
Any way for a party to have multiple hosts for redundancy, like how you
can have multiple MX and NS records in DNS?
In practice it's a few hundred ms of exposure, but it's still possible.
Then we slow down to blockchain speed.
Regarding the refund address. Thanks for adding that to the issue
requests. I guess I'm confused how this is going to work safely. If you
put a refund request in with your payment, isn't that revealing the
public key of your node and then defeating the whole purpose of the
onion routing of the payment in the first place (I'm, assuming the payee
node re-uses the same public key?)? It seems like rather than putting a
flag in BOLT 11 to instruct a payer to include a refund payment request,
shouldn't the payer just know to do that if they think they will need
to? Or maybe they won't always?
Nobody along the route (B and C in our example above) can see it. And D
kind of has to, since it needs to send the refund.
It seems to me like this is sort of a limitation in privacy with
lightening. With blockchain payments on my fuel pump, I could return a
refund back to the customer without always knowing who they are. With
lightning, it looks like the payer will reveal their identity to the
payee by offering a refund payment request. It's great that those along
the payment route don't know, but it's still bad to have the payer
revealed to the payee. Why does someone have to reveal their identity
just to get a refund?
But there needs to be some way for D to tell A it wants a refund
address, hence a flag in BOLT 11.
I guess it won't hurt to be explicit.
In BOLT 11, how does a payee distinguish payments from different payers?
In standard bitcoin transactions, this is usually by different bitcoin
addresses that have been presented to different payers. Is this what the
purpose of the d and h tagged fields are?
In this case 'p' is the payment-specific variable.
Gotcha.
In BOLT 11, in the examples section, for the p tagged field, it lists it
as a "preimage". Is this supposed to be a "preimage hash"?
Oops, thanks!
https://github.com/lightningnetwork/lightning-rfc/pull/235
In BOLT 11, what's the point of tagged field n if the public key is
implied through the signature and the required recovery id?
I like key recovery, but there were some question marks over it. So if
we decide doing key recovery is a dumb idea, we can start using the n
field. Since everyone should support it, it's a trivial change.
Makes sense.
Cheers!
Rusty.
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
