From joseph at lightning.network  Wed Jul 15 18:54:47 2015
From: joseph at lightning.network (Joseph Poon)
Date: Wed, 15 Jul 2015 11:54:47 -0700
Subject: [Lightning-dev] Routing on the lightning network?
In-Reply-To: <87io9m6u0d.fsf@rustcorp.com.au>
References: <874mlm0z5k.fsf@rustcorp.com.au>
	<1436295968.4352.49.camel@hppg6.kloosterkade>
	<87pp43v6rp.fsf@rustcorp.com.au>
	<1436900084.4523.87.camel@hppg6.kloosterkade>
	<87io9m6u0d.fsf@rustcorp.com.au>
Message-ID: <20150715185447.GA13942@lightning.network>

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