MSC3184: Challenges Messages #3184

BillCarsonFr · 2021-05-10T08:35:19Z

In matrix we already have vibrant discussions going on in rooms, but we often miss a fair method to resolve a dispute between several parties.

This proposal improve matrix by adding several methods to fairly choose between several options by:

Defining the standard shape for extensible challenges messages, such as
- Rock/Paper/scissors
- Coin Flip
- Drawing Straws
Defining extensible commitment schemes allowing to define the level for binding vs concealing property of the challenge

BillCarsonFr · 2021-05-10T14:36:10Z

How it could look like in timeline

uhoreg · 2021-05-10T15:21:20Z

proposals/3184-challenges.md

+
+
+Each participant will choose one of the straws, by commiting to a number [1,n].
+In order to resolve disputes, each participant must commit the straws by order of preference, e.g (1,3,2,4). If straw 1 was already taken, then try to peek 3, and so on.


If two people choose straw 1, how do you determine which one gets straw 1, and which one needs to use their second choice?

I think based on m.challenge.commit event timestamp? then eventId order?
will update

you can easily forge event timestamps

But we will all see the same?

Sure, but it means a person on their own homeserver where they can forge ts can then ensure that they get their choice vs fallback

It isn't beneficial to forge the timestamp because you don't know what the straws are, no choice is better than any other. All that matters is that we can decide who picked what before the shuffle is revealed.

How? Since the reveal only happens after the events have been sent there isn't an issue. Unless you are talking about people adding an event after the reveal and spoofing it to appear like it came out before?

If it is the latter we could include a hash of the selected responses at the time of reveal. Of course the proposer could potentially be accuses of selecting the order to make their preferred participant win.

I could use the order of users in the m.challenge tofield instead of timestamp.
"to": ["@bob:exemple.com", "@alice:exemple.com", @jhon:exemple.com,..]

kevincox · 2021-05-12T23:10:27Z

proposals/3184-challenges.md

+
+
+Each participant will choose one of the straws, by commiting to a number [1,n].
+In order to resolve disputes, each participant must commit the straws by order of preference, e.g (1,3,2,4). If straw 1 was already taken, then try to peek 3, and so on.


It isn't beneficial to forge the timestamp because you don't know what the straws are, no choice is better than any other. All that matters is that we can decide who picked what before the shuffle is revealed.

kevincox · 2021-05-12T23:12:26Z

proposals/3184-challenges.md

+`===`
+`=`
+`==`
+`====`


How are the shuffle and choices serialized?

kevincox · 2021-05-12T23:14:00Z

proposals/3184-challenges.md

+## Alternatives
+
+
+## Security considerations


Colluding parties can reliably win. For example the flipper can tell the guesser out of band or the shuffler can share the order with the player that they want to win (or lose).

kevincox · 2021-05-12T23:15:27Z

proposals/3184-challenges.md

+
+
+## Alternatives
+


There is an MSC for polls. However this is notably different because it is about secret selection.

However this may have some overlap with a future bind-poll proposal which may wish to use similar techniques as the ones used here.

In fact it may be worth considering a generalization of this MSC which could support the following:

Blind polls/simultaneous sharing. A system where participants can submit their proofs and they once the proofs are collected the actual values can be sent. This solves the "you go first" issue as you know that the answers didn't influence one another. This could be used to implement the straw picking example.

Collaborative random choices. This could be used both for the coin-flip challenge as well as provably fair random picks in general. (Example: everyone submits a random value using a simultaneous share and the hash of all of the values is used to select a choice)

kevincox · 2021-05-12T23:24:50Z

proposals/3184-challenges.md

+
+
+## Potential issues
+


What happens if some clients don't support some or all of the challenges? Right now there is no negotiation. This basically means that humans would need to do the negotiation before starting a challenge. It may be worth considering auto-negoation so that clients can indicate which challenges are supported by all members of the room. This would be extra useful for the commitment strategy as it would make sense to automatically fall back to an older method if it isn't supported by everyone involved.

kevincox · 2021-05-12T23:27:35Z

proposals/3184-challenges.md

+    "type": "m.challenge.commit",
+    "content": {
+        "commitment": <sha256(✌️ || rA)>
+        [...]


How do we know who is involved? If I am in a group chat but want to challenge one person is there any automatic UX or is this left up to humans? This can be especially relevant if there are multiple groups in a room that have different challenges at the same time. For example imagine I am running a small tournament and each match needs to play rock-paper-scissors to decide who goes first, or each group needs to draw straws. Without some built-in targeting mechanism there will probably be a lot of people answering the wrong challenges.

There is a to field that indicates the intended targets:

Relevant:

https://en.m.wikipedia.org/wiki/Coin_flipping#Telecommunications

ghost · 2023-05-26T22:41:47Z

Two ideas:

This could be done as an extention for pools, so clients that does not implement this MSC could also participate if they support pools. We also benefit from all the work and debugging done on pools.
Coin flip should not be choosen manually like rock-paper-scissors, it is much more intuitive for coin flip to be automatic. We can do it by making Alice and Bob clients randomly choose 0 or 1, then XOR it. This way we get fairly choosen random boolean number :).
This could also work in bigger rooms, let's set a timer and display message saying "Flipping...". If the timer runs out or all members choose 0 or 1, we do XOR on them all.

Challenges MSC

37042ff

BillCarsonFr force-pushed the bca/challenges branch from 964e74f to 37042ff Compare May 10, 2021 08:36

BillCarsonFr changed the title ~~Challenges MSC~~ MS3184: Challenges Messages May 10, 2021

BillCarsonFr marked this pull request as draft May 10, 2021 08:38

turt2live added client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels May 10, 2021

uhoreg reviewed May 10, 2021

View reviewed changes

kevincox reviewed May 12, 2021

View reviewed changes

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live changed the title ~~MS3184: Challenges Messages~~ MSC3184: Challenges Messages Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

kevincox mentioned this pull request Sep 7, 2021

MSC3381: Polls (mk II) #3381

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC3184: Challenges Messages #3184

MSC3184: Challenges Messages #3184

BillCarsonFr commented May 10, 2021 •

edited

Loading

BillCarsonFr commented May 10, 2021

uhoreg May 10, 2021

BillCarsonFr May 10, 2021 •

edited

Loading

t3chguy May 10, 2021

BillCarsonFr May 10, 2021

t3chguy May 10, 2021

kevincox May 12, 2021

kevincox May 13, 2021

BillCarsonFr May 14, 2021

kevincox May 12, 2021

kevincox May 12, 2021

kevincox May 12, 2021

kevincox May 12, 2021 •

edited

Loading

kevincox May 12, 2021

kevincox May 12, 2021

uhoreg May 26, 2023

TheDidek May 18, 2024

ghost commented May 26, 2023



		Each participant will choose one of the straws, by commiting to a number [1,n].
		In order to resolve disputes, each participant must commit the straws by order of preference, e.g (1,3,2,4). If straw 1 was already taken, then try to peek 3, and so on.

MSC3184: Challenges Messages #3184

Are you sure you want to change the base?

MSC3184: Challenges Messages #3184

Conversation

BillCarsonFr commented May 10, 2021 • edited Loading

BillCarsonFr commented May 10, 2021

Choose a reason for hiding this comment

BillCarsonFr May 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevincox May 12, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost commented May 26, 2023

BillCarsonFr commented May 10, 2021 •

edited

Loading

BillCarsonFr May 10, 2021 •

edited

Loading

kevincox May 12, 2021 •

edited

Loading