Jonathan Underwood <junderw...@bitcoinbank.co.jp> writes:
> Hi all,
>
> I have mentioned this to roasbeef re: lnd implementing it... but I am
> wondering if this idea has propagated through the LN community and whether
> other wallets are going to implement it?
>
> Feature:
>
> If the recipient of a payment waiting for a specific r_hash receives
> an open_channel message with push_msat >= the value of the request where
> the temporary_channel_id contains the r_hash... that payment will be set to
> a WAITING_OPEN status.
>
> Once the channel is open, the payment moves to a PAID status.
>
> If while waiting for channel to open in the WAITING_OPEN state, a routed
> payment is received with the r_hash, accept that payment and change the
> payment status to PAID.
Hi Jonathan,
It's an interesting idea, but I think I prefer simply opening a
channel then making a payment rather than using push_msat. Otherwise
the payer doesn't get proof of payment for this case.
> 1. Open_channel can take up to 10 minutes, but most smartphone apps kill
> background network processes for apps after 5 minutes or so.
Worse, open_channel can take *hours* if the depth requirement is high,
the fees too low, or miners unlucky.
> 2. If routing fails to pay someone. A wallet UI should ask the user:
> "You have enough on-chain funds to send. What would you like to do?
> 1. Open channel & send
> 2. Send on-chain
> 3. Give up"
Generally it's better to open a channel, though sending onchain is
possible if they provided a fallback address.
> 3. If we choose 1 in the current implementations, we would need to open a
> channel, then wait... then remember to re-open the app as soon as the
> channel is open. Then we need to paste the payment request again.
I'm sure there are ways for mobile wallets do the kind of polling needed
here, and respond accordingly. They can certainly disconnect in the
meantime.
> 4. By allowing the person to "pay" with an open_channel, it allows people
> to signal intent to pay... allowing payment processors that generate
> payment requests with short expiration times to react to that intent
> accordingly.
It introduces trust into the system though; either you're prepared to
offer longer settlement terms, or you aren't. I don't think you should
adjust based on such a falsifiable signal?
> I think this might be good to add into BOLT 2... what does everyone
> think?....... not sure.
FWIW, this would be a 1.1 thing, since spec is frozen other than
outright bugs.
Thanks!
Rusty.
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
