Alright, I have another approach that uses this threshold scheme, the previous ECDSA threshold scheme (with the t' = 2*t - 1 limitation), and Bitcoin's multisig. This scheme is more flexible. When delegate participation is at least 93, the reserve cannot be compromised by a colluding group of less than 49 delegates. If delegate participation drops below 93, it is possible (under normal circumstances) to enter a recovery mode in which the reserve can be recovered by at least 73 participating delegates (however, between the time of entering this recovery mode and fully recovering the reserve, the reserve is vulnerable to a colluding group of 28 delegates).
Procedure:
Segment the top 100 delegates into 10 disjoint regions of 10 delegates each. Each region can use a 7-of-10 threshold scheme (the one without the t' = 2*t - 1 limitation). This requires setting up (10 choose 7) = 120 different 7-of-7 subsets for each region. Since signature generation in each region will require a 7-of-7 scheme, it means it will require 19 rounds and take approximately 30 seconds.
If 97 of the top 100 delegates participate in a threshold signature scheme (the old t' = 2*t - 1 limited one) to create a backup key, it means 49 of the top 100 delegates can collude to recover the backup private key.
We can require a 9-of-15 multisig to protect the reserve where 10 of the keys are the threshold public keys for each region and the remaining 5 keys are copies of the backup key.
If the right 49 delegates collude they can generate 7 signatures corresponding to 7 of the first 10 keys in the multisig, as well as recover the backup key for a total of 8 signatures corresponding to 12 of the 15 keys (this satisfies the 9-of-15 multisig). However, if any 48 of the top 100 delegates collude they can only generate 6 signatures corresponding to 6 of the first 10 keys in the multisig and they cannot reconstruct the backup key and therefore do not have the necessary signatures to compromise the reserve.
Under normal operation, the backup key should not be used. In this case all 9 signatures must come from regions. In the worst case scenario (in terms of halting the gateway), all 10 regions could have at least 6 participating delegates each (total of 60 so far) and in addition 8 of these 10 would each have all 10 participating delegates. This gives a total of 92 participating delegates but only 8 signatures. To generate the last signature under normal operation would require one more participating delegate for a total of 93 of the top 100 delegates participating.
However, under fallback operation the backup key could be recovered and so only 4 signatures corresponding to the first ten keys would be needed. In the worst case scenario (in terms of halting the gateway), all 10 regions could have at least 6 participating delegates each (total of 60 so far) and in addition 3 of these 10 would each have all 10 participating delegates. This gives a total of 72 participating delegates but only 3 signatures. To generate the last signature one more participating delegates would be needed for a total of 73 of the top 100 delegates participating. Also, when one of the chosen delegates is able to recover the backup private key this delegate could collude with a minimum of 27 other delegates to compromise the reserve. Thus in fallback mode the minimum number of colluding delegates needed to compromise the reserve is actually 28 not 49.
Finally, if it was not possible to get at least 97 of the top 100 delegates to participate in the generation of the backup key, then this scheme must fallback to using a 7-of-10 multisig instead where the 10 keys are again the threshold public keys for each region. In this case, if less than 85 of the top 100 delegates are participating, the reserve could potentially be stuck. Also, it would take a minimum of 49 of the top 100 delegates to collude to compromise the reserve.
Summary:
As long as the backup private key is never reconstructed (only needs to happen during fallback operation), then it is not possible for less than 49 of the top 100 delegates to ever compromise the reserve by colluding together. If the private key is reconstructed during fallback operation, then 28 colluding delegates of the top 100 delegates could potentially compromise the reserve if the private key was reconstructed on the machine of a delegate that was one of the colluding 28.
There are three different modes of operation: normal mode, no-fallback-available mode, fallback-activated mode. There is a minimum number of participating delegates for each mode that will guarantee that the gateway will be able to function (below that number it is possible, but not necessarily likely, that the gateway will halt unless the fallback operation is activated if possible). Under normal mode, if at least 93 of the top 100 delegates are participating then the gateway is guaranteed to continue operating (if this is not true and the gateway is stuck, it is possible to active fallback operation). Under no-fallback-available-mode, if at least 85 of the top 100 delegates are participating then the gateway is guaranteed to continue operating (if this is not true and the gateway is stuck, there is no fallback to rely on). Under fallback-activate mode, if at least 73 of the top 100 delegates are participating then the gateway is guaranteed to continue operating (if this is not true and the gateway is stuck, there is no additional fallback to rely on).
When initiating the scheme, normally the keys and multisig will be set up to allow normal mode of operation. This however requires at least 97 of the (new) top 100 delegates to participate in the set up process for the keys each time the set of top 100 delegates changes. If this is not possible at the time of a change to the set of top 100 delegates, then the keys and multisig will be set up (with the new top 100 delegates) to allow a no-fallback-available mode of operation. During the no-fallback-available mode, if at any time at least 97 of the top 100 delegates become available (even without the set of top 100 delegates changing) the keys and multisig can be updated (and the Bitcoin reserve moved) to upgrade the mode of operation back to normal mode.