[Nakamoto] Capping Signer Weight

[AshtonStephens]

This is a discussion post around capping signer voting weight such that any individual signer can only have voting power of some fraction of the system.

Relevant Draft SIP: SIP-021 #155
SIP Economics: economics.md

The signing threshold for signing a block and voting is currently planned to be 70%. The initial proposition was to cap the signing power at 69% but has evolved to capping the signing power at 25%.

• How does this impact stacker incentives?
• What happens to the rest of the votes needed?
• What are mitigation strategies to avoid too much weight being assigned to a single signer?

Note that any cap implemented for the signers should be clearly communicated to members of the system.

[AshtonStephens]

This is only dicussing the cap on the signing weight; stackers can still stack an arbitrary amount of stacks.

[jcnelson]

1. Signers still want to lock as much STX as possible because it increases their PoX rewards. However, it's easier for smaller signers to have outsized influence on sBTC and block production, and that could create additional incentives for malicious parties. We'll want to be sure that this doesn't lower the barrier to entry for someone who would just borrow STX for the purpose of stealing the BTC.

2. Not sure what the question here is?

3. Without changing anything, a signer with a lot of STX could outsource their signing power to multiple other entities without even giving them STX. They would do so by stacking their STX in many tranches, and granting third parties their signing authority for the tranche. Importantly, the third party does not need to hold STX at all.

[andrerserrano]

@jcnelson on (1) as a general design goal, wouldn't it be better to limit the influence of 'whales' and large signers who could act maliciously? I don't see how giving more influence to smaller signers would negatively impact the system, since they would still need to obtain 70% of signing power. If one signer could obtain 69% it would be significantly easier than if the threshold was 25%.

[jcnelson]

I'm less worried about whales because they have more to lose if the system breaks. Also, whales are more likely to be conservative in what they do, because they have taken on more risk by taking a larger position.

I'm much more worried about opportunists who can wield power without proportional downside risk for wielding it badly.

[andrerserrano]

It seems like that's a risk of delegating signing in general: it decouples the risk of locked STX from signing incentives.

[jcnelson]

If your delegate screws up, your STX are still locked and your PoX payouts are still burnt. Delegation does not free you of risk; it actually makes it slightly worse because you have no agency to fix your broken / offline signer.

[jcnelson]

Look, the main guarantee I'm after is to ensure that the voting power you are granted is less than or equal to the risk you take. That is, if you stack X% of the STX in a reward cycle, you should receive <= X% of the votes. Is there a vote allotment scheme that can do this, while also ensuring that no single stacker receives more than 25% of the votes?

[muneeb-ali]

Some comments on this. First, I want to acknowledge that the 69% limit just introduces one hop that someone needs to jump i.e., if there really is just a single signer then that party can delegate/transfer to a new address and boot up a new signer on a different IP, appearing as 2 signers to the network. So this limit check should be thought of more as a "reasonable default setting" than some hard cap that malicious parties can't bypass.

So with that in mind, I think a 25% limit can be more reasonable than 69% as the "reasonable default setting". There are two reasons for this:
(a) Having less than 4 signers on the network is a pretty bad scenario from a decentralization perspective, so the reasonable default settings should encourage at least 4 or more signers.
(b) Having close or north of 30% signing power with a single signer can be problematic because a >30% signer going offline can result in withdraws temporarily suspended (no money can move without >70% signing). Even if you are the same operating entity, let's say a large staking provider, and you need to boot up two different nodes to avoid hitting 25% limit. That is still a good practical outcome, where there is some redundancy that one node got knocked out (for whatever reason) and the other kept working.

In the grand scheme of things, I'd say this is not a very critical decision that we need to make. As I said earlier, this is really about picking "reasonable defaults", so I listed some arguments for why 25% might be better but I can be happy with the current default of 69% as well -- thanks!