You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out remaining uses of is_pre_funded_state and rename it
`Channel::is_pre_funded_state` is used to mean several different
things. In the past few commits we stopped using it for a few
conflicting uses, but here we break out the remaining uses and
rename the remnants for clarity.
`is_funding_broadcast` was using `is_pre_funded_state` and was then
later used to decide if the `Channel` could be written to disk
(because it can be resumed on restart), if we should broadcast a
force-close transaction, and when to emit a `ChannelPending` event.
These were also somewhat divergent - we shouldn't generate a
`ChannelReady` event or broadcast a force-closing transaction until
we've actually broadcasted but want to write the `Channel` to disk
once we enter funding signature exchange for dual-funded open.
Thus, the ability to write a `Channel` to disk is provided by a new
`can_resume_on_restart` method. Then, `is_funding_broadcast` is
updated to only consider funding broadcasted after we provide our
funding signatures (i.e. the funding *could* have been
broadcasted). This is still a bit early to generate a
`ChannelPending` event (as the funding may not actually have been
broadcasted yet), but its better than it was.
Finally, the remaining `is_pre_funded_state` is renamed
`can_resume_on_reconnect`, which has slightly different semantics
than on-restart channels in batch opens.
0 commit comments