From pm+lists at acinq.fr  Thu Sep 24 10:25:11 2015
From: pm+lists at acinq.fr (Pierre)
Date: Thu, 24 Sep 2015 12:25:11 +0200
Subject: [Lightning-dev] Minor protocol revisions.
In-Reply-To: <87r3lo2wsi.fsf@rustcorp.com.au>
References: <87r3lo2wsi.fsf@rustcorp.com.au>
Message-ID: <CAMXsxZNq_guYvgdBGSGqwk5b5DWYJj-EY0uqm53DJKGKoHm=Xw@mail.gmail.com>

Hi Rusty,

> 1) Close now has an second ACK stage, which means you know the close ack
>    has been received.
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 ?

> 3) HTLC rejection (eg. bad route, insufficient fees) added.
How about the 'commit tx too big' case ? will that just be an error ?

> As a secondary effect, 32 bits places [an upper bound of 0.04 BTC]
> (currently about $10USD) on each HTLC.  That's more than enough to cover
> the micropayment uses of lightning, yet if you lose all your money due
> to a horrible bug in the early days, I can buy you a beer and count us
> about even[1].  And we can change the protocol later if it becomes
> overly limiting.
Such a low ceiling bothers me a little bit, because it kind of states
that the micropayment use case is the primary target. Is it ? To me,
scalability and speed are the most interesting properties of
lightning. I would have preferred a higher (1 BTC ?) limit, but I
understand this can be changed. Regarding the risk of bugs, you can't
loose more than the channel capacity so that's another parameter we
can play with I guess.

Cheers,

Pierre