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
Create Packet-specified Delay period that ensures that a delayPeriod amount of time has passed between the creation of a consensus state and when it can be used for verification of the packet functions (recv/ack/timeout). This ensures that there is at least some time available for a relayer to submit Misbehaviour and invalidate the consensus state before it gets used to process this packet.
Since different users may have different tolerances for risk, we allow it to be defined at packet-level so all users may use a single client while still choosing their own level of risk-tolerance with regards to race conditions between their packet getting processed and potential misbehaviour-submission.
NOTE: The above proposal was found to be insecure since an attacker could simply forge a packet with a 0 delay period. The delay period is specified at the connection-level, fixed at the start of the handshake. Modules that are transferring packets with value must take care to properly separate liquidity pools into the channels that they originated from.
The text was updated successfully, but these errors were encountered:
Create Packet-specified Delay period that ensures that a
delayPeriod
amount of time has passed between the creation of a consensus state and when it can be used for verification of the packet functions (recv/ack/timeout). This ensures that there is at least some time available for a relayer to submit Misbehaviour and invalidate the consensus state before it gets used to process this packet.Since different users may have different tolerances for risk, we allow it to be defined at packet-level so all users may use a single client while still choosing their own level of risk-tolerance with regards to race conditions between their packet getting processed and potential misbehaviour-submission.
NOTE: The above proposal was found to be insecure since an attacker could simply forge a packet with a 0 delay period. The delay period is specified at the connection-level, fixed at the start of the handshake. Modules that are transferring packets with value must take care to properly separate liquidity pools into the channels that they originated from.
The text was updated successfully, but these errors were encountered: