From rusty at rustcorp.com.au  Tue Oct 13 19:52:50 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 14 Oct 2015 06:22:50 +1030
Subject: [Lightning-dev] Minor protocol revisions.
In-Reply-To: <CAMXsxZO34=-7Qo9GohhEGu=pFPDEXmc-kGLrqB-gK-60pLZkLw@mail.gmail.com>
References: <87r3lo2wsi.fsf@rustcorp.com.au>
	<CAMXsxZNq_guYvgdBGSGqwk5b5DWYJj-EY0uqm53DJKGKoHm=Xw@mail.gmail.com>
	<20150929064740.GA9432@navy>
	<CAMXsxZO34=-7Qo9GohhEGu=pFPDEXmc-kGLrqB-gK-60pLZkLw@mail.gmail.com>
Message-ID: <878u76im0d.fsf@rustcorp.com.au>

Pierre <pm+lists at acinq.fr> writes:
>>> Argh, I already have trouble understanding the rationale behind all
>>> the existing closing flows and states :-s Would it be possible to
>>> publish an updated version of the svg ? aj, any chance you could do
>>> the same with your 'flat' version ?
>>
>> Yeah. I've updated state.py so the following flow works:
>
> Thanks!
>
> I guess what I'm missing about all those closing states is the reason
> why we need to handle combinations of the 3 basic cases (current
> commit, revoked commit or mutual close).
>
> This cannot happen since they all spend the same anchor right ? Why do
> we care if they are broadcasted and not confirmed ?

We need to keep watching until (any one of them) is buried deep enough
that we don't care (say 100 deep).  Otherwise a revoked transaction +
chain reorganization could cheat us of funds.

These details are what makes a robust implementation so difficult :(

Cheers,
Rusty.