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
{{ message }}
This repository was archived by the owner on Apr 23, 2024. It is now read-only.
the channel needs a way to signal what the current close state is (eg. need to close, or in the middle of closing). This PR introduces a flag for that, but other channel state is inferred from the latest agreements. See if we can do something similar with that.
Also, we'll need to unify using the close state in code outside the ingest code, eg. when proposing/confirming a close, and when checking to see if we can propose/confirm new payments it should be checking against this.
The text was updated successfully, but these errors were encountered:
an option is we could store on the channel the initiator escrow account sequence number. And then infer from that what the close state is.
eg. if it's the latestCloseAgreement declTx then were in CLOSING, if it's less than that but greater than our starting seqNum then we're in NEEDS_CLOSING
edit: this is what this PR is doing. After that is merged, this ticket will be to track that the validations of when allowed to propose/confirm close agreements is checking against this new close state
I've renamed this issue to expose state as an enumeration. I think we need a single enum that captures what the known on-network state of the channel is. We can still develop close and open states separately then combine them. The state should only be affected by ingestion.
the channel needs a way to signal what the current close state is (eg. need to close, or in the middle of closing). This PR introduces a flag for that, but other channel state is inferred from the latest agreements. See if we can do something similar with that.
Also, we'll need to unify using the close state in code outside the
ingest
code, eg. when proposing/confirming a close, and when checking to see if we can propose/confirm new payments it should be checking against this.The text was updated successfully, but these errors were encountered: