Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-15 📝 Original message: On Wed, Jul 15, 2015 at ...

📅 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