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
A dishonest domain owner or especially the user that opened the newest channel between two domains, have the ability to close a communication channel immediately to avoid processing incoming messages they do not wish to handle. This capability allows the domain owner or (more likely) that user to selectively block or discard messages that they don't like, and harm the platform's reputation.
Risk
A dishonest domain owner or user can manipulate the system by selectively blocking legitimate messages, which can lead to data loss or incomplete data processing. This in the long run will also negatively impact Subspace's reputation and user trust.
Mitigation
Introduce a delay mechanism for channel closure requests. This allows pending messages to be processed before the channel is fully closed, preventing immediate blocking.
The text was updated successfully, but these errors were encountered:
vanhauser-thc
changed the title
[LOW] XDM - Dishonest domain owner or domain user can close channel to avoid processing messages
[Low] XDM - Dishonest domain owner or domain user can close channel to avoid processing messages
May 30, 2024
@vanhauser-thc This issue does not exist once we have the open PR - #2829 merged to main.
To go in further. Since Closing channel uses the same nonce flow of endpoint messages. Let see some examples
Channel between src_chain and dst_chain is open and src_chain closes the channel
Users sends some endpoint messages
Channel owner decided to close the channel.
On the dst_Chain, the channel close request will not be processed until previous nonces are processed. So all the previous messages will be processed.
For Endpoint responses, we do not check the state of the channel since endpoint message initiatation will only happen if the given channel is open.
Once the responses of the above user messages are recieved, they are processed in that order including the channel close request
Channel between src_chain and dst_chain is open and dst_chain closes the channel
User send some messages
Simultaneoulsy dst_chain closes the channel
When the message is received on the dst_chain, since the channel is already closed on dst_chain but waiting to be closed on src_chain, we accept the message and dst_chain will return an err response to the src_chain about channel being closed.
Once the response is received on the src_chain, it will revert the necessary actions taken. For transporter, this will give the funds to the user.
Issue Description
A dishonest domain owner or especially the user that opened the newest channel between two domains, have the ability to close a communication channel immediately to avoid processing incoming messages they do not wish to handle. This capability allows the domain owner or (more likely) that user to selectively block or discard messages that they don't like, and harm the platform's reputation.
Risk
A dishonest domain owner or user can manipulate the system by selectively blocking legitimate messages, which can lead to data loss or incomplete data processing. This in the long run will also negatively impact Subspace's reputation and user trust.
Mitigation
Introduce a delay mechanism for channel closure requests. This allows pending messages to be processed before the channel is fully closed, preventing immediate blocking.
The text was updated successfully, but these errors were encountered: