Make Channel::pending_monitor_updates TLV even
#2317
Assignees
Milestone
Comments
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Jul 5, 2023
In 9dfe42c, `ChannelMonitorUpdate`s were stored in `Channel` while they were being processed. Because it was possible (though highly unlikely, due to various locking likely blocking persistence) an update was in-flight (even synchronously) when a `ChannelManager` was persisted, the new updates were persisted via an odd TLV. However, in 4041f08 these pending monitor updates were moved to `ChannelManager`, with appropriate handling there. Now the only `ChannelMonitorUpdate`s which are stored in `Channel` are those which are explicitly blocked, which requires the async pipeline. Because we don't support async monitor update users downgrading to 0.0.115 or lower, we move to persisting them via an even TLV. As the odd TLV storage has not yet been released, we can do so trivially. Fixes lightningdevkit#2317.
jkczyz
changed the title
Channel::pending_monitor_updates TLV eventChannel::pending_monitor_updates TLV even
jbesraa
pushed a commit
to jbesraa/rust-lightning
that referenced
this issue
Jul 11, 2023
In 9dfe42c, `ChannelMonitorUpdate`s were stored in `Channel` while they were being processed. Because it was possible (though highly unlikely, due to various locking likely blocking persistence) an update was in-flight (even synchronously) when a `ChannelManager` was persisted, the new updates were persisted via an odd TLV. However, in 4041f08 these pending monitor updates were moved to `ChannelManager`, with appropriate handling there. Now the only `ChannelMonitorUpdate`s which are stored in `Channel` are those which are explicitly blocked, which requires the async pipeline. Because we don't support async monitor update users downgrading to 0.0.115 or lower, we move to persisting them via an even TLV. As the odd TLV storage has not yet been released, we can do so trivially. Fixes lightningdevkit#2317.
optout21
pushed a commit
to optout21/rust-lightning
that referenced
this issue
Jul 24, 2023
In 9dfe42c, `ChannelMonitorUpdate`s were stored in `Channel` while they were being processed. Because it was possible (though highly unlikely, due to various locking likely blocking persistence) an update was in-flight (even synchronously) when a `ChannelManager` was persisted, the new updates were persisted via an odd TLV. However, in 4041f08 these pending monitor updates were moved to `ChannelManager`, with appropriate handling there. Now the only `ChannelMonitorUpdate`s which are stored in `Channel` are those which are explicitly blocked, which requires the async pipeline. Because we don't support async monitor update users downgrading to 0.0.115 or lower, we move to persisting them via an even TLV. As the odd TLV storage has not yet been released, we can do so trivially. Fixes lightningdevkit#2317.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With 116 we should make the pending monitor updates an even TLV as we won't support downgrades to 115 for users of the async monitor update pipeline. I also plan on moving the unblocked ones back out to
ChannelManagerto make handling #2168 simpler.The text was updated successfully, but these errors were encountered: