In general, we have limited attack windows whenever we limit behavior by VRFs. I think a 1/3rd adversary has like an expected 1 attack slot per day vs polakdot’s soundness, although those computations should really be checked. That’s across all cores, so really adversarial_cores/total_cores < 1 attack slots per day.
We should slash like 250% aka two backers and partially several approval voters, although not sure that’s implemented, which could drive this lower if the restaking options enforce some independence, like polakdot itself does.
In other words, there is a non-zero but manageable risk that a backing validator who gets slashed for another task could successfuly attack polkadot duringthe time period while they’re still a validator.
It’s dubious this makes much sense for a BTC bridge. Instead, we discovered that polkadot can run large DKGs, so if we want a BTC bridge then all 1000 validators could participate inthe DKG, and 667 participate in each signature.
I think restaking should be fine for collators though, since we bascially assume they’re malicious anyways. Restaking should work fine for protocols like TLSNotary too, which yields nice oracles.
In theory, (re)staking plus TLSNotary plus SNARKs of bank transactions permit “decentralized stable coins”, in which many small accounts held EUR and the parachain monitors their transactions. I’ve no idea if that’s legal though.
Interestingly, restaking also makes sense for trad fi insurance deposites, like catastrophe bonds, which sound completely indepedent from whatever polkadot does. We’d want some enforcement that different stakers catastrophe bonds were uncorrolated, because a correlated sell off there causes other problems.