Is your feature request related to a problem? Please describe.
Presently, when the old_vault initiates a redeem::request_replace action, it locks griefing collateral using the request_vault_issue call within redeem::request_replace. This seems unnecessary since the old_vault has already locked collateral, known as backing collateral, which can be used as griefing collateral. This additional collateral requirement places an undue burden on the old_vault.
Describe the solution you'd like
The preferred solution is to refrain from locking collateral in the old_vault during the redeem::request_replace process. Instead, if the old_vault fails to submit the BTC transaction before the expiry, the backing collateral should be slashed.
Describe alternatives you've considered
An alternative solution, which is currently implemented, involves locking extra collateral through the request_vault_issue call.
Additional context
The original issue was discussed in this comment.
Is your feature request related to a problem? Please describe.
Presently, when the
old_vaultinitiates aredeem::request_replaceaction, it locks griefing collateral using therequest_vault_issuecall withinredeem::request_replace. This seems unnecessary since theold_vaulthas already locked collateral, known as backing collateral, which can be used as griefing collateral. This additional collateral requirement places an undue burden on theold_vault.Describe the solution you'd like
The preferred solution is to refrain from locking collateral in the
old_vaultduring theredeem::request_replaceprocess. Instead, if theold_vaultfails to submit the BTC transaction before the expiry, the backing collateral should be slashed.Describe alternatives you've considered
An alternative solution, which is currently implemented, involves locking extra collateral through the
request_vault_issuecall.Additional context
The original issue was discussed in this comment.