Couldn't the witness just change other data in their block until they get an s value that they like?
Yes, you are correct. I don't know what I was thinking.
So we would still need a 20-byte commit in the previous round, however, not of some other 20-byte random data but rather of the r value instead. The r value would still be revealed along with the s value in the signature, but it would do double duty as the entropy source. This would save only 20 bytes per block rather than 40 bytes (so 0.6GB per year rather than 1.2GB per year).
Also, to clarify an unrelated point, anytime a witness was producing a block in a round in which they did not produce a block in the previous round, the blockchain would allow them the option to use an r value that is not consistent with the last commit of an r value that is associated with their witness, in order to avoid producing a signature that could reveal the signing key.
So, I guess it may not be worth it to try to preserve the provably fair RNG functionality of witnesses and leave that role to something else in the blockchain.
However, I did like the idea of witnesses being an entropy source for the blockchain, and I do have another idea for how we could get that "for free" with another functionality that I find very useful. If you take a partial Schnorr signature of the previous block digest by some subset of the active witnesses and combine them together, you get a Schnorr signature of the previous block digest signed by a key that is the sum of public keys associated with the block signing keys of the witnesses in that subset. The point of the nonce value of the combined signature is also random if any of the witnesses in the subset used a random nonce in their partial signature. So the block producer could collect these partial signatures from all the witnesses (they can be of the previous block or perhaps the block before the previous block to help with latency issues), combine them together, and include it in the block header. The blockchain would only accept that signature in the block header (by the way, this is in addition to the block signer's regular signature of the block they are producing) if all of the active witnesses contributed to the signature. This signature would act as a much faster checkpoint signature than waiting for 0.51*(number of active witnesses)*(block interval) seconds for the same confirmation security, at the cost of an extra signature per block. Of course, if a block producer is not able to get all the partial signatures in time they would exclude the combined signature from the block header which they are allowed to do. In that case clients simply have to fallback to waiting longer until they get the confirmation.
By using the latest point of the nonce in the combined signature as part of the random number generator, we get a RNG that has the same properties as the current RNG (in that as long as a single witness is honest, the generated number is random). However, a new random number is generated (and thus new entropy is available to the blockchain) much faster
in practice (the random number generated each block is provably fair, rather than having to wait a full round to guarantee that you get new entropy that is provably fair in our current system), but
in theory it may take an indefinite amount of time to actually generate a provably fair random number since each block producer could exclude the combined signature from block header (for example because there is a single active witness who is not complying with the process). Of course this functionality comes at a cost. Instead of
reducing the blockchain bloat by 1.2GB per year by getting rid of the RNG, it would
add 0.8GB per year for these combined signatures (we could instead get similar functionality while
reducing blockchain bloat by 0.2GB per year instead of 1.2GB per year if we only allow combined signatures on every other block at the cost of slightly longer waiting to get the faster confirmation). So, it all comes down to how much the faster confirmation feature is worth it to people.