📅 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:47:30
in reply to nevent1q…4cav
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:47:30Event JSON
{
"id": "11e5368e6780d11363465a3ad8658fb46f765dc2c2dc526af469aaf500662c61",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314850,
"kind": 1,
"tags": [
[
"e",
"9d76f21d5978f30a2fe9fae19181e368ba9ba67befaee80be653edf19ef4e82c",
"",
"root"
],
[
"e",
"fc938794024b47e8aabd2c5b2a6e38aae4fa70bb1c70a8f429d59983b188edea",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2017-09-04\n📝 Original message:\nOn Mon, Sep 04, 2017 at 10:04:01AM +0930, Rusty Russell wrote:\n\u003e Not currently, no: paying the same payment request twice is an\n\u003e invitation for anyone in the middle to just take your funds!\n\u003e \n\u003e With 1.1 we're looking at changing the way payment hashes work so this\n\u003e will be possible (kind of like bip32, except for lightning).\n\nWe could allow for amount adjustments while the payment has not been\nresolved. So let's say the sender would like to perform incremental\npayments to a recipient. The recipient issues a payment request that\nindicates support for adjustments. The sender now sends an initial\ntransfer to the recipient through a route of her chosing. The\nrecipient does not immediately claim the transfer by revealing the\npreimage, instead it serves the sender and keeps the transfer\nopen. The sender now increments the amount by sending an updated\nadd_htlc message with matching payment hash and a higher value. Nodes\nalong the route notice that this is an update to an existing HTLC, and\nforward it along the route (resetting any timeouts to unlock the\nHTLCs).\n\nThis could allow for payments similar to the simple Spillman style\npayment channels, but routed along a path or multiple hops, but it\nobviously has some pitfalls as well, e.g., it opens a new DoS vector\nwhere an attacker can lock up funds for a longer time, so we need to\nbe careful about how we implement these.\n\nCheers,\nChristian",
"sig": "5cc91e7c89da84609cf760e90c7438a360775879f90c5b8d34393b3c29b6e051c2288c0e42c84e2bddf3a763c9ac1d44234cc297b95a8e8ec4e390f54b7321fd"
}