📅 Original date posted:2015-07-15
📝 Original message:
On Wed, Jul 15, 2015 at 11:51:06AM +0930, Rusty Russell wrote:
> Perhaps we can rig something that requires the recipient to pay more
> according to time?
>
> Joseph?
It's definitely possible, depends on what kind of complexity you're
comfortable with. I think Tadge brought up the idea a long time ago
about using the timelock for decay of payments with one's counterparty
for on-chain enforceability. E.g. A current Commitment has 50
sub-commitments which pay out different lightning fee values with later
locktimes.
Presume an HTLC has a 0.09 value with 0.01 allocated to fees (refunds
back to Alice any extra fees). If we are currently at Commitment #123,
we have Commitment123_1, Commitment123_2, and Commitment123_3. Each have
very similar payouts, with very minor differences in HTLC fees paid and
the locktime.
Assuming some kind of full on-chain Replace-By-Fee, you
can prioritize Commitment123_3 over Commitment123_2 on-chain, but
Commitment123_3 will also have a higher fee on lightning as well.
However, Commitment123_3 can only be broadcast at a later date, so
"earlier" Commitment123 values can be valid. Things can get a little
wonky at the edges, so you have to arrange the fees such that if there's
some time asynchronousness along the chain, that intermediary nodes
don't lose out (functionally I think this means the time-decay will be
somewhat marginal and be a small percentage of the total lightning fees
paid).
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:43:34
in reply to nevent1q…up7m
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:43:34Event JSON
{
"id": "674ece99012027b00dd18d0b3213c06cdc4725b46df7e008c8bcece6789138ed",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314614,
"kind": 1,
"tags": [
[
"e",
"b051b897d36d9747c0a2ead17e2be0eb4114a547258d74b54d7d8da5c672c214",
"",
"root"
],
[
"e",
"500fcad41c03d42a15eabea9cc443349519faa1ea3957a0490a6fc27dede959f",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-07-15\n📝 Original message:\nOn Wed, Jul 15, 2015 at 11:51:06AM +0930, Rusty Russell wrote:\n\u003e Perhaps we can rig something that requires the recipient to pay more\n\u003e according to time?\n\u003e \n\u003e Joseph?\n\nIt's definitely possible, depends on what kind of complexity you're\ncomfortable with. I think Tadge brought up the idea a long time ago\nabout using the timelock for decay of payments with one's counterparty\nfor on-chain enforceability. E.g. A current Commitment has 50\nsub-commitments which pay out different lightning fee values with later\nlocktimes.\n\nPresume an HTLC has a 0.09 value with 0.01 allocated to fees (refunds\nback to Alice any extra fees). If we are currently at Commitment #123,\nwe have Commitment123_1, Commitment123_2, and Commitment123_3. Each have\nvery similar payouts, with very minor differences in HTLC fees paid and\nthe locktime.\n\nAssuming some kind of full on-chain Replace-By-Fee, you\ncan prioritize Commitment123_3 over Commitment123_2 on-chain, but\nCommitment123_3 will also have a higher fee on lightning as well.\nHowever, Commitment123_3 can only be broadcast at a later date, so\n\"earlier\" Commitment123 values can be valid. Things can get a little\nwonky at the edges, so you have to arrange the fees such that if there's\nsome time asynchronousness along the chain, that intermediary nodes\ndon't lose out (functionally I think this means the time-decay will be\nsomewhat marginal and be a small percentage of the total lightning fees\npaid).\n\n-- \nJoseph Poon",
"sig": "0748512c906f32cdb27a399b31a8c9ec13fe98095b857c9ab19ba9664acb5032d729c6177418a875019816443f725fcf67ca27bff8ba06b79f00e59ff59256e6"
}