Good morning Matt,
> I can't imagine the constants add up that fast... Allow 25 channels per peer
> and limit your peers reasonably and the cost should be low enough. Really not
> sure why something like a 25 channel limit should limit any usage or
> reasonably burden a node, what am I missing?
I can't imagine the constants add up that fast... Allow 25 channels per peer
and limit your peers reasonably and the cost should be low enough. Really not
sure why something like a 25 channel limit should limit any usage or reasonably
burden a node, what am I missing?
On January 15, 2018 2:14:5
Good morning Matt,
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> Original Message
> Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message
> Local Time: January 15, 2018 9:00 AM
> UTC Time: January 15, 2018 1:00 AM
> From: lf-li...@mattcorallo.c
Good Morning Richard,
> Original Message
> Subject: Re: [Lightning-dev] [Question] Unilateral closing during fee
> increase.
> Local Time: January 14, 2018 8:37 PM
> UTC Time: January 14, 2018 12:37 PM
> From: richard.ha...@gmail.com
> To: Peter Todd
> lightning-dev@lists.linux
Sounds to me like the lack of a protocol-required minimum timeout is the issue.
Because the cost of tracking an unopened channel is relatively trivial, I see
limited reason to bother notifying the peer that a channel has timed out.
However, due to potentially radically different concepts for wha
Complete n00b question here: if one side of the channel have 100% of the
funds, can the last message give that user complete controll over the
channel (to close it "unilateral" without any interaction from the other
side?
And that way change the fee size when that part want's to close the channel?
On Sun, Jan 14, 2018 at 10:30:28AM +0900, Jonathan Underwood wrote:
> Hey everybody.
>
> Say that the last time we updated channel state, we assumed 40 satoshi/byte
> was enough to get confirmed, then I leave the channel for a few weeks, come
> back to find my partner fell off the face of the inte
