wip-0019: submit draft

[aesedepece]

Solve #68

[lrubiorod]

I will assign you the wip number WIP-0019

[lrubiorod]

Technically, the protocol admit a secuence of bytes different of 32, but it will be handle in Tally creation to adapt to 32 bytes (zeropadding or cutting)

[aesedepece]

Still they MUST do so. What they are free to do is to ignore the MUST 🤣

[aesedepece]

I would be ok with changing it for SHOULD to acknowledge that there's no way to enforce it.

[tmpolaczyk]

What should happen when there is a retrieval script? Should that script be executed or ignored? This sentence seems to imply that it should be ignored?

[aesedepece]

In the absence of any specific mention, everything follows the original logic and the script should be executed.

[aesedepece]

Do we want to forbid scripts on RNG sources? I guess there's not much use to them, but who knows.

[tmpolaczyk]

If we forbid scripts we can save 1 byte because [] is not a valid script, we currently must use [128]. Other than that, the only use case I see for allowing scripts would be to try to write a malicious request that looks like a random request but the script makes it deterministic.

[drcpu-github]

I can see a use for scripts where you'd process the random number on the Witnet blockchain already thereby limiting the number of calculations that need to happen in the smart contract? Currently I don't think enough operators are supported to do useful processing, but that may change in the future.

[aesedepece]

I'm unsure about the point of doing any kind of operation on the "local" randomness, that is, before aggregating the reveals form multiple witnesses.

A different question would be if an script could be provided such that it is applied on the result upon tally. I do believe that would be more in line which was drcpu has in mind (e.g. going from uniform to normal, mapping the randomness to a specific range, etc.)

[drcpu-github]

Yes, I'm talking about a tally script, I missed the context of this being at the aggregation step (though I'm not sure if it would harm being able to do this in the aggregation stage too).

[aesedepece]

If we forbid scripts we can save 1 byte because [] is not a valid script, we currently must use [128]. Other than that, the only use case I see for allowing scripts would be to try to write a malicious request that looks like a random request but the script makes it deterministic.

Nice point. Btw in a future WIP we could introduce implicit typing of scripts and other structures (remove the first byte because it's always 128)

[tmpolaczyk]

I'm unsure about the point of doing any kind of operation on the "local" randomness, that is, before aggregating the reveals form multiple witnesses.

If the computation happens before the commit-reveal steps, the result is impossible to prove and therefore insecure. The early versions of witnet used to allow arbitrary scripts in the tally stage, but that was removed for some reason I don't remember, most likely for simplicity.

[aesedepece]

I don't remember either why we gave up on tally scripts, but I must recognize at this point I don't see any issue with them other than additional complexity.

[mariocao]

The other very unlikely attack would be a DoS attack in which a REVEAL transaction is "denied" during the reveal_extra_rounds period. For that to happen, an attacker would have to be able to mine 4 blocks consecutively.

[aesedepece]

I included a paragraph stating this more explicitely