allow round number to not be included

[wighawag]

This is important for use case that do not want to make the round number public right away

fixes: https://github.com/drand/tlock-js/issues/5

[AnomalRoil]

We won't support this by default I think, unless we have a good usecase for it.

What's your usecase @wighawag ?

[wighawag]

@AnomalRoil the feature is crucial for commit+reveal scheme where knowing the time of reveal would allow someone to guess the information being encrypted.

This is the case for my game https://conquest.game and any game using that feature

For example in conquest, if you send some fleet and people know the time of reveal, they can suddenly know that the destination planet must be in a specific radius.

[wighawag]

Hi @AnomalRoil I am now working on my use-case that will use drand and tlock-js

I would like to know if you intend to support the feature this PR implements. This is a required feature for me and don't see a reason why the round number MUST be included.

Furthermore as mentioned, for some use-case, including the number can reveal information you might not want to.

[CluEleSsUK]

If we were to do this change, my suggestion would be that we provide a round number of 0 when encrypting. This should make it eas to support in the go CLI. As for decryption, I'm not sure what the best practice would be.

We could provide a client that requests every round sequentially and tries to decrypt, but this would a) be expensive to run b) cost us a lots of money for beacon retrieval from our API. Decryption could take an expected time range or only try rounds from now onwards, but these both have limitations too. Decryption could take an Array<RandomnessBeacon> and users could retrieve and cache the beacons out of band, but this would preclude listening for future beacons to decrypt.

A final consideration is that we want the solution to be hard to misuse - if users start accidentally creating ciphertexts for round 0 or pulling every beacon in the universe for something they should know the round for, we're gonna have a bad time

[wighawag]

Re decryption, the idea is that the user of tlock-js would take care of it

For my use case, the player would provide a period value of x rounds, for example it could be 1 hours worth of round and so the service decrypting would only need to make an attempt once an hour.

[CluEleSsUK]

I see - so a way to set the round stanza to 0 on encryption and pass an arbitrary beacon for decryption would do the job?

[wighawag]

yes, that should do

Else I wondering if we could have a lower level api that do not use the armor part ?

[CluEleSsUK]

Could easily add a flag to timelockEncrypt to make armor optional! Decryption works with armored and unarmored out of the box