Hey @Cryptouf
What are the other reasons that make the bound non-breakable?
For each dealing we need to collect support shares from the receivers. How many shares should we collect? In the protocol we collect 2f+1, which is actually the maximum assuming up to f corruptions: if you want to collect more support shares then the protocol cannot guarantee liveness, since you would need the participation of possibly corrupt parties to make progress. Therefore in the protocol we have that each dealing has support from 2f+1 receivers, however you don’t know a priori how many of the supporters are honest. Since we assume up to f corruptions, then it means we have at least f+1 honest supporters for each dealing. So in the worst case the f+1 honest supporters need to be able to sign, which means that the threshold can be at most f+1. AFAIK this issue applies in general to interactive DKG protocols.
Is that normal that there isn’t a check in the code for the other reasons, which would raise an error for my working (10,5) scheme?
There are several checks in place. We run the protocol on certain agreed parameters, for which we verify several invariants upon creation. See e.g. here.
Finally, have you explored some solutions to remove the f<n/3 bound, as described here for example?
Yes we did explore solutions to increase the safety threshold. However, they inherently require to reduce the liveness/availability threshold. This was explained, e.g., in this forum post where we highlighted the possibility of increasing the security threshold while sacrificing on liveness. This for example could be useful to reshare towards smaller subnets, while keeping a comparable security threshold. Note that reducing liveness also increases the risk of losing the key, e.g. in case too many nodes break, which is also a risk to take into account.