sBTC Design - Coordinator selection / handling unresponsive signers (VRF)

[stjepangolemac]

We need to figure out how to pick coordinators aming signers in a deterministic and safe manner.

Selection VRF

1. For every signer take its public key and concatenate with additional data — pk|last_block_hash|sbtc_operations_processed
2. Get the selection ID by hashing the resulting data and put them into an array
3. Numerically order selection IDs
4. Pick the first selection ID as the coordinator

Notes

• If the picked coordinator is not responsive pick the next one from the sorted array of selection IDs
• Maybe the counter sbtc_operations_processed is not needed and something like last_sbtc_op_btc_txid is enough?
• Maybe the combination of last_block_hash and sbtc_operations_processed or last_sbtc_op_btc_txid can be gamed and be known in advance, I guess it depends how often the coordinator is picked compared to the block production rate

Final

1. Take the public key for every signer and the latest sortition VRF seed, hash them together and produce a selection ID
2. Numerically order selection IDs
3. Pick the first selection ID as the coordinator
4. Optionally pick the next ID if the first signer is unresponsive

[stjepangolemac]

The signer work is something almost completely new to me, so it's possible none of the above makes sense.

Do you think this, or something similar, could work for the coordinator selection? Also, in the case of unresponsive signers can we just move on to the next selection ID in the sorted array?

cc @jferrant @soju-drinker @jcnelson

[jferrant]

As far as I am aware, the last_block_hash would be extremely difficult to game though in theory of course possible but it is at least as difficult as gaming the Bitcoin block hash. To game the last block hash on bitcoin, you would need to execute a 51% attack successfully so in theory we would need to execute a 51% attack on bitcoin and then subsequently on stacks, no? I think having the coordinator change per stacks block might work really nicely. I don't think sbtc_operations_processed would be required...but I don't imagine it would be hard to add in if it is. @jcnelson ?

[stjepangolemac]

I've thought something along those lines. The thing that bugs me is that we've mentioned multiple times that after Nakamoto block times will be ~10 seconds.

Isn't that too often to pick a coordinator?

[stjepangolemac]

This was discussed in one of the sBTC design calls. The agreement is that for additional data to add to the public keys before hashing we can use the latest sortition VRF seed. That produces selection IDs that can't be known in advance.