@xdustinface

Also, did you think about just making a separate DIP out of this? I honestly don't have a strong opinion on wether it should be separate or not but i think it could make sense to make a new and refer to this one. Thoughts?

I thought about it initially but imo it's ok to have this as an update because the core idea is the same - use (potentially) multiple LLMQs to secure the chain. The difference is basically that in signing attempts it was (up to) 2 quorums - one was signing the attempt and (potentially) another one was finalizing CLSIG while in MQ CLs every LLMQ just signs its own CLSIG for whatever block it considers the right one and then anyone can aggregate these CLSIGs to agree afterwards. So it's more like an evolution of the initial proposal rather than a radically new idea imo.

I'm not sure I understand the reasoning behind this change. Could you elaborate more @UdjinM6? Taking control of a 400 member quorum requires close to 60% of the network or 50% and a lot of hash power. If you are afraid this is not enough we could use a higher threshold quorum, and/or have more members.

The idea is to make ChainLocks as robust as possible basically. We can avoid some issues by tweaking the way we handle ChainLocks internally by applying stricter rules to CLSIG messages (see dashpay/dash#3978) but it can potentially make ChainLocks more fragile in edge cases e.g. when network is under high load and blocks aren't propagated fast enough. The solution proposed here solves that.

@xdustinface Makes sense, picked both. Thanks! 👍

Is the "Calculations" section still accurate with this change? Also, I was thinking it might be nice to include a link to the original version of the document (whatever the most recent change was) so people can easily refer back to it. I think that could be added to the "Prior Work" section.

Is the "Calculations" section still accurate with this change?

Should be accurate for a single LLMQ mode but yeah, for a multi-quorum mode you'd need to disrupt 2 quorums (or control 3 quorums to produce invalid clsig) at the same time, so I guess you should take all these probabilities roughly to the power of 2 (or 3 respectively) or so? Let's ping @DarrenTa :)

Also, I was thinking it might be nice to include a link to the original version of the document (whatever the most recent change was) so people can easily refer back to it. I think that could be added to the "Prior Work" section.

Hmm... current version in master is https://github.com/dashpay/dips/blob/81e81b52799114191729364ed36dc0e372062fbe/dip-0008.md but I'm not sure if it makes a lot of sense to link back to itself, especially in a git repo..

Thank you so much for the ping. I can provide the following:

1. I can review this change and form an opinion, backed by data, if this should be live or not.
2. I do agree with @QuantumExplorer above. I would want a comparable security level out of the new process.
3. I almost wonder if a straight up multisig would be the way to go? The threshold setup does require overhead.
4. In response to @thephez perhaps DIP0008 should not be edited at all. It would be best to make a new DIP and then change the status of 0008 (to something like superseded).

I have cited DIP0008 in my academic work, it would make my citations cleaner if DIP0008 was not changed significantly. I was lazy and did not put date accessed.

I've also cited (withdrawn) 0005 and think the citations provide for a robust discussion, even if not live. No reason 0008 has to be edited to agree with the live implementation.

I'll circle back here in a week and report back with a proper analysis.

Hmm.. ok, you guys convinced me to at least create an alternative PR to have smth to compare to :) Pls see #89.

closing in fav of #89