How large does the largest turnNum need to be?

force-move
2
  1. A max turnNum of 2^48 = 2^10 * 2^25 * 2^13 would allow for a channel where ~1000 states were exchanged every second for the next 8000 yrs. Which seems like plenty.

Just a note on this throughput: If you were 300km apart (how far light goes in 1ms in a perfect vacuum), and exchanging 1000 states per second, the application and wallet would need to work with zero computation time.

  1. A timestamp of 2^34 gets us to Wednesday, May 30, 2514 1:53:04 AM, so even if finalizesAt stays in seconds, 2^40 should be sufficient.

A potential issue with this is if the block timestamp gets changed to milliseconds. However, that scenario would probably require a migration to a new adjudicator anyway, since any challenges that begin just before the fork would not behave as intended.

Also keen to hear opinions on the smallest values we could get away with. (If we could fit in a couple of turnNumbers into the bytes32, along with finalizesAt and the channelStorageHash, it opens up more options.)

If Alice and Bob have a high-throughput virtual channel, they can reset the turnNum to zero by starting a new virtual channel with an agreed-upon outcome, and then switch the funding from the old channel to the new channel. With this technique, even 16 bits might be enough.

It seems like your application+wallet needs to either
A1) gracefully handle a turnNum reset using this technique; or
A2) rely on never running out of turns in a given channel

For A2, I feel like you might need at least 32 bits, while for A1, it doesn’t seem like there’s any practical difference between 16 and 24 bits.