Good morning CJP, Rusty, and list,
> > But why do we need consensus at all? There are two versions of each
> >
> > commitment transaction: one to be used for unilateral close by one peer
> >
> > (A), and one to be used by the other (B). Peer A has an interest in
> >
> > "commit transaction A",
CJP writes:
> Hi,
>
> Maybe this is a stupid question, and it is late so maybe I'm
> overlooking something, but I don't want to lose a potentially good
> idea, so here it goes:
>
> Right now, BOLT#3 imposes a certain algorithm for fee estimation. This
> algorithm is likely to be sub-optimal: fee e
Jim Posen writes:
> Thanks for the thoughtful responses.
>
>> You missed the vital detail: that you must prove channel closure if you
>> can't unpeel the onion further. That *will* hit an unresponsive party
>> with a penalty.
>
> Ah, that is a good point. I still find the proposal overall worryin
On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote:
> > The big concern I have with _NOINPUT is that it has a huge failure
> > case: if you use the same key for multiple inputs and sign one of them
> > with _NOINPUT, you've spent all of them. The current proposal kind-of
> > limits the p
