Alice and Bob commit to their rolls by hashing them then making a future spend contingent on revealing the roll that produced the hash.
The trick is how to reveal both rolls without giving an advantage to the one who reveals second. This is the problem the protocol solves - through transaction setup and the newly-activated Script opcodes.
What you are describing is a coin flipping protocol [0].
From the article:
>To my knowledge this is the first time someone has proposed such a scheme on Bitcoin though I suppose it's possible it has come up before and I just missed it.
There have been coin flipping protocols for Bitcoin since at least 2013-2014 [1]. The main contribution of the above post appears to be that they actually performed the protocol which is neat and quite a bit of work.
[0]: https://en.wikipedia.org/wiki/Commitment_scheme#Coin_flippin...
[1]: Back, Bentov (2014) https://arxiv.org/abs/1402.3698
[0]: https://eprint.iacr.org/2013/784
[1]: https://curiosity-driven.org/bitcoin-contracts
[2]: https://blockexplorer.com/tx/7ae5760af2105a5ba54a914f188686e...
[3]: https://blockexplorer.com/api/tx/7ae5760af2105a5ba54a914f188...
https://bitinfocharts.com/comparison/transactionfees-btc-eth...
Transaction costs are specified by the protocol in satoshis, which is the base unit of Bitcoin. How much you can buy for one satoshi only depends on what people want to pay for it. We call this the coin value.
A coin without value is free to transact with. Run your applications on testnet if there are no other considerations.
Also a very clever hack to get around the scripting limitations by using the length of the secret instead of the actual secret itself.
You could implement chess with only movement commitments and no atomic fair random number generation.
PS: Adding numbers mod X will provide a fair random number as long as at least one side provides a fair random number to start with. Which is a stronger guarantee if your making a real money wager.
are they perfectly even or is one more likely for each flip?