Would this be a valid implementation for an ether staking pool if the goal was to eliminate the need for depositors to forfeit control of their ether to the pool owner?
Depositor creates a contract and sends the ether they wish to stake to that contract
The contract controls 2 of 3 keys in a multisig address and the pool owner controls the other key
The pool owner calls a function in the contract, providing info on the block they want to vote on
The contract would then generate a signature for the block using one of the depositors two keys and return the signature to the pool owner
The pool owner would also create a signature using the key they control
Together, the signatures from the depositor and pool owner constitute proof of ownership of the staked ether and therefore a vote for whatever block the pool owner provided info on
The pool owner would then be able to submit a vote and repeat the process all over again
The contract would have a spending limit of 0 ether unless the keys used to sign a tx included both of the depositors keys (prevent pool operator from stealing funds)
I was reading about the necessity of speed in updating block votes to reduce lost funds due to DDoS here, and was trying to think of possible implementations that would prevent the depositor from introducing additional delay into the voting process.
If the pool needed to request a signature from a depositor, and the depositor had their ether staked using an 'EthPool-Qt' client running locally that generated signatures for the pool, wouldn't the delay introduced by the network significantly increase the potential not switching votes fast enough, getting left on the losing side, and therefore losing the ether at stake?
Do you think pools that require depositors to forfeit control of their ether will have an advantage in staking because they can simply vote on blocks because they would literally own all of the depositors ether and could create votes without needing to collect additional signatures?
