From rusty at rustcorp.com.au  Sat Apr 30 05:45:27 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Sat, 30 Apr 2016 15:15:27 +0930
Subject: [Lightning-dev] Concurrent sigs in BOLT #2
In-Reply-To: <CAL3Hpbd2GO3ob-TiiqMW03afYAfv3MsWJfXxeY7n1yq+KPxYgw@mail.gmail.com>
References: <CAMXsxZNfubpao256ACamUvBHsL-59X3K9LjA3ACpbgUC1F4v6A@mail.gmail.com>
	<878u015cvn.fsf@rustcorp.com.au>
	<CAL3Hpbd2GO3ob-TiiqMW03afYAfv3MsWJfXxeY7n1yq+KPxYgw@mail.gmail.com>
Message-ID: <871t5n4pl4.fsf@rustcorp.com.au>

Fabrice Drouin <fabrice.drouin at acinq.fr> writes:
> Hi!

Hi!

>> Now, at this point both nodes have outstanding changes, so they can send
>> another SIG (which acks the received changes, thus modifying the other
>> state):
>>
>>     Committed: [Y]                                Committed: [X]
>>     States:    [Y] [X Y]                          States: [X] [X Y]
>>                     SIG A1 ---          --- SIG B1
>>                               \        /
>>                                \      /
>>                                 \    /
>>                                  \  /
>>                                   \/
>>                                   /\
>>                                  /  \
>>                                 /    \
>>                            <----      ----->
>> PROCESS ACK:
>>     Committed: [Y]                                Committed: [X]
>>     States:    [X Y] [X Y]                        States: [X Y] [X Y]
>> PROCESS SIG:
>>     Committed: [X Y]                              Committed: [X Y]
>>     States:    [X Y] [X Y]                        States: [X Y] [X Y]
>>
>
> What if instead of immediately sending a new SIG, A and B then decide
> to send each
> other a new HTLC? Could we get stuck in an infinite loop where A and B
> never converge on a
> commitment tx?

Yep, they need never converge (though they probably will).  But you
don't really care; as long as an HTLC committed to by both sides, it's
locked in.  Until then the receiver can't offer it onwards.

And once it's no longer in both side's committed tx, it's invalid;
before then the offerer must watch if it is getting close to the
deadline:

BOLT #2:

        Thus a node MUST estimate the deadline for successful redemption
        for each HTLC it offers.  A node MUST NOT offer a HTLC after
        this deadline, and MUST fail the connection if an HTLC which it
        offered is in either node's current commitment transaction past
        this deadline.

> Or should it be specified that the only valid answer to a signature is
> either a signature (if there
> are outstanding changes) or a revocation ?

I think you should be able to pack in as many updates between signatures
as you want (though there's a 1500 maximum htlcs in the spec).

Whether you offer other things is independent of whether you're being
slow on signatures.

Cheers,
Rusty.