I reviewed your Upgraded SHA-Gate contract and its supporting documents. Looks really good to me. Wish this had been done from the start back in Aug `21.
I have a couple questions and comments:
M-of N for operator keys: 3-of-5 (can easily be extended to 5-of-7 or even larger)
What would you say is the “maximum” for N
? It appears to be limited by how many public keys can be submitted to the contract during initWithdrawal
.
In my Bailout plan, I suggest that “single-digit” N
is insufficient. Historical evidence has shown that these smaller quorums have sufferd greatly from having their keys compromised. How is often “undetermined”, which often lends to the notion of an “inside” job.
I aim to increase N
to at least 20, but ideally, I’m hoping to support 100+ Validators during each quorum. To do so, I’m thinking of using a Merkle-tree style system of Covenants-of-Covenents. eg. if the maximum number of Validators per covenent is say 10
, then we could have 10
individual contracts, that each use 1 N
slot in the “Master” Covenant, which would then effectively support 100 Validators.
Does that make any sense? Would you know how to do something like that or recommend a better solution to increasing the number of participating Validators?
As outlined above this version works with a fixed length voting period and proposes to extend this to 2016 blocks (~2 weeks, which is the same length as the epoch for validator election).
Even with batching each withdrawal, 2 weeks seems like an awfully long time to have to wait on a withdrawal. Can you explain in more detail how this would work in practice? Who would typically be making these withdrawal requests? How would they manage the delay in receiving their assets?
BCH still uses 20 byte P2SHashes for smart contracts which opens them up to profitable collision attacks when holding balances upwards of a few hundred thousand USD (see post on Bitcoin Cash Research forum). SHA-gate is less vulnerable to this attack as it only allows operators to add arbitrary data to the state.
Could you explain what the “worst case” scenario is here? Could someone potentially empty the contracts funds? Block withdrawls? I’m assuming this is a “general” BCH problem as well, so it is probably low-risk otherwise I imagine it would have already been addressed.
whether to have miners or elected enclaves monitor the withdrawals
+1 elected enclaves
whether to have one main contract holding all the funds and batch withdrawals or have many separate UTXOs
+1 all-in-one, batched
I couldn’t quite make sense of the Diagram (not really my thing), but I plan to review ALL OF IT again next week and hopefully offer some additional feedback…
Cheers!