This is a tracking issue for the root cause of a number of issues,
listed at the bottom. The issue at hand is that up until #7027
we had an issue that could result in the signer state being updated,
but the CLN state not reflecting that change. With #7027 this
issue has been resolved, however nodes that were in this situation
cannot back out of it, as that would equate to a replay of an old
state, and the validation is there to explicitly prevent that.
If VLS were to implement a mode (as a SimpleValidatorFactory
argument?) that tells VLS to temporarily opt out of the enforcement of
this policy, we could use that to get the nodes unstuck, close the
channel, and get back to a situation where the VLS and the CLN state
match up again.
Discussing this with @ksedgwic, the signer will always sign based on
its local state, and so the options are two:
Patch the state before invoking: this is essentially overwriting
the signer state with whatever the node is reporting back, ensuring
that the local state and the state provided by the request match
up. This would mean that the special permissive mode doesn't have
to be wired through the call-stack, but involves introspecting the
state in two places (the patching side and the processing side).
Wire the special mode through to the verification, and base
descisions on the request transaction, rather than the local state
transaction. This would involve more code changes as both have to
be handed down the call-stack, as well as a flag to signal which
state to use for signing, but most of that is already passed down
for verification of equality anyway.
The VLS team will likely know which variant (a) fits better with their
general architecture, and (b) cause the least amount of disturbance
for what is after all a relatively rare occasion (that could manifest
in different ways in the future, so a clean architecture and
extensibility is desirable here to get users unstuck).
This is a tracking issue for the root cause of a number of issues, listed at the bottom. The issue at hand is that up until #7027 we had an issue that could result in the signer state being updated, but the CLN state not reflecting that change. With #7027 this issue has been resolved, however nodes that were in this situation cannot back out of it, as that would equate to a replay of an old state, and the validation is there to explicitly prevent that.
If VLS were to implement a mode (as a
SimpleValidatorFactoryargument?) that tells VLS to temporarily opt out of the enforcement of this policy, we could use that to get the nodes unstuck, close the channel, and get back to a situation where the VLS and the CLN state match up again.Discussing this with @ksedgwic, the signer will always sign based on its local state, and so the options are two:
The VLS team will likely know which variant (a) fits better with their general architecture, and (b) cause the least amount of disturbance for what is after all a relatively rare occasion (that could manifest in different ways in the future, so a clean architecture and extensibility is desirable here to get users unstuck).
Related issues