Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-04 📝 Original message: On Mon, Sep 04, 2017 at ...
📅 Original date posted:2017-09-04
📝 Original message:
On Mon, Sep 04, 2017 at 10:04:01AM +0930, Rusty Russell wrote:
> Not currently, no: paying the same payment request twice is an
> invitation for anyone in the middle to just take your funds!
>
> 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).
We could allow for amount adjustments while the payment has not been
resolved. So let's say the sender would like to perform incremental
payments to a recipient. The recipient issues a payment request that
indicates support for adjustments. The sender now sends an initial
transfer to the recipient through a route of her chosing. The
recipient does not immediately claim the transfer by revealing the
preimage, instead it serves the sender and keeps the transfer
open. The sender now increments the amount by sending an updated
add_htlc message with matching payment hash and a higher value. Nodes
along the route notice that this is an update to an existing HTLC, and
forward it along the route (resetting any timeouts to unlock the
HTLCs).
This could allow for payments similar to the simple Spillman style
payment channels, but routed along a path or multiple hops, but it
obviously has some pitfalls as well, e.g., it opens a new DoS vector
where an attacker can lock up funds for a longer time, so we need to
be careful about how we implement these.
Cheers,
Christian
📝 Original message:
On Mon, Sep 04, 2017 at 10:04:01AM +0930, Rusty Russell wrote:
> Not currently, no: paying the same payment request twice is an
> invitation for anyone in the middle to just take your funds!
>
> 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).
We could allow for amount adjustments while the payment has not been
resolved. So let's say the sender would like to perform incremental
payments to a recipient. The recipient issues a payment request that
indicates support for adjustments. The sender now sends an initial
transfer to the recipient through a route of her chosing. The
recipient does not immediately claim the transfer by revealing the
preimage, instead it serves the sender and keeps the transfer
open. The sender now increments the amount by sending an updated
add_htlc message with matching payment hash and a higher value. Nodes
along the route notice that this is an update to an existing HTLC, and
forward it along the route (resetting any timeouts to unlock the
HTLCs).
This could allow for payments similar to the simple Spillman style
payment channels, but routed along a path or multiple hops, but it
obviously has some pitfalls as well, e.g., it opens a new DoS vector
where an attacker can lock up funds for a longer time, so we need to
be careful about how we implement these.
Cheers,
Christian