Skip to main content
Ethereum

Return to Answer

some text clarifications.
Source Link
Kyle Baker
Kyle Baker
  • 752
  • 6
  • 16

Digital vs. Analog communication?

In "Chinese Whispers" (Americans know this game as "Telephone", btw), a source of error is supposed to primarily be the analog transmission of voice itself. Here there would be no such mechanism. Anyone can see the last thing perfectly--there is no mechanism that equates to 'whispering', I guess--unless your front end intentionally swaps out some percentages of chars, or some equivalent.

But if the point is just that someone can intentionally distort the message and you do want to continue with this idea...

Secrets on the blockchain

you can store secrets on the blockchain, you just have to encrypt them. How would you do this?

  1. The NEXT user posts their public key (let's call it pub_key_next).
  2. The CURRENT user takes pub_key_next and encrypts the starting secret with it.
  3. NEXT user now becomes CURRENT user. He (and no one else) can not only view the current secret message, but decrypt and read it.

When a new user submits their public key and says they want to become the new NEXT user, then the current user can encrypt whatever they want (either the same message they saw, or a variation on it, or something completely different), and submit it encrypted so that only NEXT can view it.

And so on.

The technical part sounds complex, but actually the GUI can handle it pretty well--the tricky part is that you can't really submit the new message until the next user shows up (unless you want to include an off-chain database into the mix).

Basically, the front end should do the encrypting and decrypting, and hide that from the user. The flow would look like:

  1. User submits that they want to be the NEXT in line. (Front end in the background submits their public key to blockchain, possibly generating a public/private key pair on their behalf.)
  2. CURRENT then has to be notified, or check and notice randomly, that there is a NEXT user available. He then submits his message. (Front end in the background encrypts the message he writes with the public key of the NEXT user that's on chain, and submits itstores the encrypted message on-chain.)
  3. NEXT user, who now becomes CURRENT user, is notified that the message is now there, and goes to view it. (Front end in the background decrypts and shows them the message.)
  4. the new CURRENT user waits for a new NEXT user, and the cycle repeats.

Your last issue (isOwner bypass)

When you adopt this new setup, the issue becomes irrelevant. They will be able to look at the encrypted whisper if they want, it will be garbled nonsense.

Digital vs. Analog communication?

In "Chinese Whispers" (Americans know this game as "Telephone", btw), a source of error is supposed to primarily be the analog transmission of voice itself. Here there would be no such mechanism. Anyone can see the last thing perfectly--there is no mechanism that equates to 'whispering', I guess.

But if the point is just that someone can intentionally distort the message and you do want to continue with this idea...

Secrets on the blockchain

you can store secrets on the blockchain, you just have to encrypt them. How would you do this?

  1. The NEXT user posts their public key (let's call it pub_key_next).
  2. The CURRENT user takes pub_key_next and encrypts the starting secret with it.
  3. NEXT user now becomes CURRENT user. He can view the current secret message.

When a new user submits their public key and says they want to become the new NEXT user, then the current user can encrypt whatever they want (either the same message they saw, or a variation on it, or something completely different), and submit it encrypted so that only NEXT can view it.

And so on.

The technical part sounds complex, but actually the GUI can handle it pretty well--the tricky part is that you can't really submit the new message until the next user shows up (unless you want to include an off-chain database into the mix).

Basically, the front end should do the encrypting and decrypting, and hide that from the user. The flow would look like:

  1. User submits that they want to be the NEXT in line. (Front end in the background submits their public key to blockchain.)
  2. CURRENT then has to be notified, or check and notice randomly, that there is a NEXT user available. He then submits his message. (Front end in the background encrypts the message he writes with the public key that's on chain and submits it.)
  3. NEXT user, who now becomes CURRENT user, is notified that the message is now there, and goes to view it. (Front end in the background decrypts and shows them the message.)

Your last issue (isOwner bypass)

When you adopt this new setup, the issue becomes irrelevant. They will be able to look at the encrypted whisper if they want, it will be garbled nonsense.

Digital vs. Analog communication?

In "Chinese Whispers" (Americans know this game as "Telephone", btw), a source of error is supposed to primarily be the analog transmission of voice itself. Here there would be no such mechanism. Anyone can see the last thing perfectly--there is no mechanism that equates to 'whispering', I guess--unless your front end intentionally swaps out some percentages of chars, or some equivalent.

But if the point is just that someone can intentionally distort the message and you do want to continue with this idea...

Secrets on the blockchain

you can store secrets on the blockchain, you just have to encrypt them. How would you do this?

  1. The NEXT user posts their public key (let's call it pub_key_next).
  2. The CURRENT user takes pub_key_next and encrypts the starting secret with it.
  3. NEXT user now becomes CURRENT user. He (and no one else) can not only view the current secret message, but decrypt and read it.

When a new user submits their public key and says they want to become the new NEXT user, then the current user can encrypt whatever they want (either the same message they saw, or a variation on it, or something completely different), and submit it encrypted so that only NEXT can view it.

And so on.

The technical part sounds complex, but actually the GUI can handle it pretty well--the tricky part is that you can't really submit the new message until the next user shows up (unless you want to include an off-chain database into the mix).

Basically, the front end should do the encrypting and decrypting, and hide that from the user. The flow would look like:

  1. User submits that they want to be the NEXT in line. (Front end in the background submits their public key to blockchain, possibly generating a public/private key pair on their behalf.)
  2. CURRENT then has to be notified, or check and notice randomly, that there is a NEXT user available. He then submits his message. (Front end in the background encrypts the message he writes with the public key of the NEXT user that's on chain, and stores the encrypted message on-chain.)
  3. NEXT user, who now becomes CURRENT user, is notified that the message is now there, and goes to view it. (Front end in the background decrypts and shows them the message.)
  4. the new CURRENT user waits for a new NEXT user, and the cycle repeats.

Your last issue (isOwner bypass)

When you adopt this new setup, the issue becomes irrelevant. They will be able to look at the encrypted whisper if they want, it will be garbled nonsense.

Source Link
Kyle Baker
Kyle Baker
  • 752
  • 6
  • 16

Digital vs. Analog communication?

In "Chinese Whispers" (Americans know this game as "Telephone", btw), a source of error is supposed to primarily be the analog transmission of voice itself. Here there would be no such mechanism. Anyone can see the last thing perfectly--there is no mechanism that equates to 'whispering', I guess.

But if the point is just that someone can intentionally distort the message and you do want to continue with this idea...

Secrets on the blockchain

you can store secrets on the blockchain, you just have to encrypt them. How would you do this?

  1. The NEXT user posts their public key (let's call it pub_key_next).
  2. The CURRENT user takes pub_key_next and encrypts the starting secret with it.
  3. NEXT user now becomes CURRENT user. He can view the current secret message.

When a new user submits their public key and says they want to become the new NEXT user, then the current user can encrypt whatever they want (either the same message they saw, or a variation on it, or something completely different), and submit it encrypted so that only NEXT can view it.

And so on.

The technical part sounds complex, but actually the GUI can handle it pretty well--the tricky part is that you can't really submit the new message until the next user shows up (unless you want to include an off-chain database into the mix).

Basically, the front end should do the encrypting and decrypting, and hide that from the user. The flow would look like:

  1. User submits that they want to be the NEXT in line. (Front end in the background submits their public key to blockchain.)
  2. CURRENT then has to be notified, or check and notice randomly, that there is a NEXT user available. He then submits his message. (Front end in the background encrypts the message he writes with the public key that's on chain and submits it.)
  3. NEXT user, who now becomes CURRENT user, is notified that the message is now there, and goes to view it. (Front end in the background decrypts and shows them the message.)

Your last issue (isOwner bypass)

When you adopt this new setup, the issue becomes irrelevant. They will be able to look at the encrypted whisper if they want, it will be garbled nonsense.