From aj at erisian.com.au  Fri Nov 27 21:27:42 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Sat, 28 Nov 2015 07:27:42 +1000
Subject: [Lightning-dev] Return to the Layered Commit Transactions?
In-Reply-To: <20151127051446.GA4583@sapphire.erisian.com.au>
References: <20151125090754.GA29895@debian> <878u5krtts.fsf@rustcorp.com.au>
	<20151127051446.GA4583@sapphire.erisian.com.au>
Message-ID: <20151127212742.GA17286@sapphire.erisian.com.au>

On Fri, Nov 27, 2015 at 03:14:46PM +1000, Anthony Towns wrote:
> On Fri, Nov 27, 2015 at 02:12:55PM +1030, Rusty Russell wrote:
> > Anthony Towns <aj at erisian.com.au> writes:
>   T = the timeout in the HTLC
>   d = the CSV delay in the HTLC
>   n = how long it takes for you to be confident someone else can't
>       doublespend an input to your transaction (ie, 10 minutes * however
>       many confirmations you want to see)
>   f = how long it takes your transactions to get the first confirmation,
>       given how much fee you pay

> At time T-d-f, if the HTLC hasn't been resolved off-chain, you want to
> publish your commitment transaction. It'll hit the chain at time T-d.

> At time T both the CTLV and CSV clauses are satisfied, so you can spend
> it. You should attempt to do so immediately. Your tx will be confirmed
> at time T+f. At time T+f+n, you'll be satisfied your tx is safe.

> T-d-f = T-t = when you decide to close the channel and hit the blockchain
> T+f+n = T+k = when you're 100% sure the HTLC is done with

So in addition: if Bob is forwarding an HTLC from Alice to Carol, then,
assuming:

  Bob knows Alice's f, call it f_a;
  Bob knows the CSV delay on his channel with Alice, call it d_a;
  Bob knows the CSV delay on his channel with Carol, call it d_c;
  Bob knows his own f and n;
  Bob knows the timeout on the incoming HTLC, T_a

  Bob wants to work out the timeout to set on the outgoing HTLC, T_b.

In order to keep the channel with Alice open, he needs to resolve the
outgoing HTLC by time T_a-d_a-f_a. And the time he's sure his outgoing
HTLC is done is T_b+f+n, so:

  T_b+f+n <= T_a-d_a-f_a

  T_b <= T_a - d_a - f_a - f - n

Also, Bob wants T_b-d-f > now, or there's no point forwarding the HTLC since
he'd have to close the channel immediately, so:

  now + d + f < T_b <= T_a - d_a - f_a - f - n

gives you constraints on the forwarded timeout based on, I think, fairly
meaningful parameters.

(You might want to add further constraints on the timeout based on fees,
of course -- the above is what you need to avoid being left holding
the bag)

Cheers,
aj