[Lightning-dev] Return to the Layered Commit Transactions?

[Anthony Towns]

On Fri, Nov 27, 2015 at 02:12:55PM +1030, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> >  Definitions:
> >   d -- the OP_CSV delay
> >   T -- top OP_CLTV timeout
> >   C -- the commitment tx is signed by B and given to A at time C
> >   P -- the commitment tx is published at time P
> >   S -- the commitment tx is spent at time S
> >   X -- the timeout at which a refund can be forced
> ...
> >    For n=4, F=4, t >= d+2 hours, so normal expiry is no later than
> >    T-d-40m, and uncooperative expiry is at T+1h20, so d+2h later.
> Is the 2 hours here due to timer tolerance?  

Nope, it's just plugging in n and F into "t >= d+10*(n+2F)".

> > Don't think it's needed either though, so long as channels have parameters
> > "t" and "k" as well as "d" to drop to the blockchain well before T
> > actually comes around.
> I'll be honest, I got lost somewhere in the alphabet reading your post.

Yeah; I'm surprised I didn't while writing it.

But while chatting with matsjj afterwards, I think I came up with a
beter explanation:

  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

(To translate to t and k, t=d+f and k=f+n))

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

> However, you might be able to help me with a related question: I
> proposed previously that if you didn't get fast resolution on an HTLC
> you'd require proof that a commit tx was published, or you'd close the
> channel yourself to create such a proof to hand back.
> 
> How would this work, timeout-wise?  We don't know how many hops are
> ahead of us.  If the rule is "wait 1 minute, if you don't get a
> response, close the channel" then everyone in the chain will close the
> channel at once.  If the timeout is in the HTLC offer, then it makes the
> message more traceable.
> 
> I can't see any obvious solution, can you?

I still hope the "fine people for keeping the channel open" idea (I
think CJP proposed it?) is possible, but I haven't tried working out if
you can make the details work when you have to drop to the blockchain,
and have multiple HTLCs in flight.

If you made the rule be something like "if the HTLC was setup at time
O with timeout T, wait until O+(T-O)/120 and close the channel" you
wouldn't have privacy problems though.

You'll still have the problem that if you're near the end of the chain
you might get left holding the bag though (ie, still having to pay the
tx amount forward (despite closing that channel), but not being able
to collect it from the other end (because you cancelled the HTLC you
forwarded, in order to keep the channel open)).

Cheers,
aj