PoX-4: Signing key & reward-address relationship and constraints

[kantai]

Per some discussions over the last week, and relevant to #4263, there's still some open questions about the relationship between reward addresses and signing keys (in particular if there's one-to-one relationships with any directionality). Essentially there's two questions.

Does each reward address correspond to exactly one signing key?

The issue with answering "yes" here is that users can "grief" reward addresses: if they stack-stx with the targeted reward address, but with a bad signing key, then any other users of that reward address need to use a new reward address. This is pretty bad, because reward addresses are generally pretty hard to rotate.

Answering "no" here means that reward addresses can be associated with multiple signing keys. The issue with this is "how do you punish bad signing key behavior?" If a reward address is associated with multiple signing keys, it shouldn't be punished to the same extent if a key it stacked a relatively low amount to misbehaved. The solution here is to track how much stacks contributed to a particular signing key from each address. This isn't too bad to implement, because this can be calculated/tracked during make_reward_set.

Does each signing key correspond to exactly one reward address?

The issue with enforcing this constraint is that users can "grief" signing keys. This is less bad than griefing reward addresses, because rotating signing keys shouldn't be too hard, but still bad because of transaction front running.

Not enforcing this constraint means that signing keys can't control who they operate on behalf of. The solution here is to require an authorization signature from the signing key whenever a signing key is set (see #4247).

My suggestion is to answer "no" to both constraints: allow multiple reward addresses per signing key, and multiple signing keys per reward address. I think the concerns about griefing are both serious enough that implementing the solutions to non-uniqueness is worth it.

[jcnelson]

In principle, after reading this, I agree "no" on both. Griefing is an unacceptable denial-of-service vector. We should implement the authorization signature scheme described in #4247.

If a reward address is associated with multiple signing keys, it shouldn't be punished to the same extent if a key it stacked a relatively low amount to misbehaved.

Right now, the idea is to have PoX payouts to the address cease if the associated signing key has failed to produce a signature for K Bitcoin blocks, and resume if they have resumed signing for K Bitcoin blocks. Are you thinking that instead of stopping the payout altogether, we flip a weighted coin (e.g. using the VRF) on PoX payouts to the offending address such that the probability of the payout being forfeited is proportional to the fraction of STX represented by the misbehaving signing keys?

[kantai]

Are you thinking that instead of stopping the payout altogether, we flip a weighted coin (e.g. using the VRF) on PoX payouts to the offending address such that the probability of the payout being forfeited is proportional to the fraction of STX represented by the misbehaving signing keys?

That wasn't what I was thinking, but I think that would work better than what I was thinking. I was thinking that the node would compute how much stacked STX "misbehaved", and if it clears slot_threshold, remove a slot.