Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The term "bets" is introduced without first explaining what it means #560

Open
vporton opened this issue May 16, 2023 · 9 comments
Open

Comments

@vporton
Copy link

vporton commented May 16, 2023

https://internetcomputer.org/docs/current/motoko/main/base/Random:

all bets must be closed before entropy is being asked for in order to decide them

The term "bets" is introduced without first explaining what it means.

@sesi200 sesi200 transferred this issue from dfinity/portal May 17, 2023
@ggreif
Copy link
Contributor

ggreif commented May 17, 2023

Well, it is the standard definition of "bet" that comes up when you type "bet definition" in Google.

Screenshot 2023-05-17 at 13 49 40

In the context of the IC this means that the external Principal must submit all its chosen symbol(s) (e.g. words or numbers for Wordle or a lottery) before the decider canister starts obtaining entropy to use for deciding the bet (that is, determining the winning value for those symbols).

@vporton
Copy link
Author

vporton commented May 17, 2023

I still don't understand:

What are "chosen symbols"? What is to "submit" a chosen symbol? How to submit a chosen symbol?

I see API to get a blob (apparently, it is called a "bet" in your terminology). I see no API to submit chosen symbols.

So, I still don't understand.

@ggreif
Copy link
Contributor

ggreif commented May 17, 2023

No worries :-)

Imagine you have (implement) a canister for a lottery. You need to define a service definition with a message to receive a sequence of numbers. Then in each drawing round you have to wait for external entities to submit their number combinations ("bets"). At some point you stop accepting bets, and then you obtain entropy (in form of a Blob) which you can use to obtain the winner. Normally you chop up the Blob in pieces and normalise the obtained numbers to be in the desired range. The mechanism is up to you and depends on the game being played. (It is crucial not to introduce bias in the process.)

So for for a lottery game the "chosen symbols" are the submitted numbers, submission happens by receiving the message from your users. The system doesn't provide an API for submitting bets to your canister, instead you define it.

The system only provides an API to your canister for obtaining cryptographic entropy (256 random bits).

@ggreif
Copy link
Contributor

ggreif commented May 17, 2023

Notably the game Wordle is a bad fit for the IC, as it requires the game canister to choose the winning symbols (5 capital letters). The bets are received after that. So (theoretically) a user could eavesdrop on the node machines and obtain the winning combination that way in one try.

@vporton
Copy link
Author

vporton commented May 17, 2023

So, what qualifies as a bet? Any inter-canister call to our canister qualifies as a bet, doesn't it? How is it determined how many bets are a enough to obtain entropy?

@ggreif
Copy link
Contributor

ggreif commented May 17, 2023

You have a non-empty set W of potential winner combinations. You receive (e.g. by inter-canister call) bets (a bet is just an element, or maybe a subset, of W) from players. The game canister then chooses the winner (picks an element of W based on freshly obtained entropy) and then goes through all the bets to assign a winning sum to them.
If W has at most 2^256 elements then one blob of entropy (from the system) should be enough to fairly pick a winner from W.

@vporton
Copy link
Author

vporton commented May 17, 2023

the external Principal must submit all its chosen symbol(s) (e.g. words or numbers for Wordle or a lottery) before the decider canister starts obtaining entropy to use for deciding the bet

Why before? Why not before or after?

@ggreif
Copy link
Contributor

ggreif commented May 17, 2023

Why before? Why not before or after?

Our cryptographers are the ones to conclusively answer this, but I'll give a try. If you ask for entropy too early, the bit sequence will be manifest in the RAM of the node machine. The decision procedure for picking the winner is also (in form of code) present on the same machine. If you are a sufficiently powerful agency or state actor then you could obtain access to those bits and programs and compute the winner. If the canister still accepts bets you can crack the jackpot :-)

If the canister pulls the entropy after all the bets are closed, this eavesdropping scenario is not possible. Of course if there are no values at stake you are completely free to ignore the recommendations.

@vporton
Copy link
Author

vporton commented May 17, 2023

So, please, change the wording from

all bets must be closed before entropy is being asked for in order to decide them

to

all bets (for example, you do a gambling software) must be closed before entropy is being asked for in order to decide them, in order to abuse the bests to guess winning combinations by using known entropy values

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants