I think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back.
Re:Smart Contract Security Field Guide
by JumpCrisscross on Wednesday July 26, 2023 @08:05PM
(#36886939)
> think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back
Bank failing in this context would be the bridge (EDIT: contract) gets hacked. Hence mitigated, but not eliminated.
If bankB is hacked, bankA still gets their money back or the payment is sent to bankC. So I still think the counterparty risk is eliminated between bankA and bankB
Re:Smart Contract Security Field Guide
by JumpCrisscross on Wednesday July 26, 2023 @08:25PM
(#36887133)
> counterparty risk is eliminated between bankA and bankB
Correct, but in its place is a new systemic risk with a real-world nonzero probability: the contract itself getting hacked. There isn't analogy for this in modern banking since the equivalent issue would either (a) get rolled back or (b) fold into the bank failing envelope. (There is analogy in pre-modern banking, though it largely revolved around debasement and invasion.)
True although I'm not talking about Ethereum smart contracts, I'm talking about Bitcoin ones which are very limited and not Turing complete. The lightning smart contract is like 20 lines and has been live since 2018, I feel the probability of the contract getting hacked is very low(famous last words!) https://github.com/lightning/bolts/blob/master/03-transactio...
This isn't a real risk with correspondent banks. Instead, it's counterparty risk: bankB failing while it holds the funds in transfer. That risk can be mitigated with smart contracts, but it's not eliminated. (Correspondent banks also take a portion of the client bank's fraud and AML risk.)