You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The query/response mechanism seems like a good place for the use of state channels. However, the current issue is the data availability problem around the timeout mechanism.
Ex: Using a state channel verifier makes a query, solver sends a response. Verifier claims solver never sent a response within the time frame (5 blocks). Solver has chance to prove they are indeed still playing. This fraud proof mechanism happens on-chain. Incentives dictate verifier pulls this trick every single query/response round because they want to see the solver lose. Then each round ends up being on-chain anyways.
Summary - In order to use state channels for query/response need to solve timeout fraud problem.
The text was updated successfully, but these errors were encountered:
Would there be any way to have a "provenly public" message exchange? If each response has a chance of being observed by a third party, who could act as a witness, then players couldn't blame each others about not receiving a message. If a player claims that the other player is pretending not to receive/see the message, he could call a random witness and the faulty player would have their deposit slashed and distributed.
@PhABC something like that would be nice. Sounds a lot like a consensus or a blockchain 😉 Possibly something that had the properties we needed but not a full blockchain.
Maybe Plasma, sidechains??? Idk, just throwing things out there.
I had some ideas around using the task giver as a third party. EX: Solver sends message to both task giver and verifier. But that is definitely subject to sybil attacks/collusion. And I'm afraid wouldn't make a verifier not try to claim fraud each round anyways.
The problem requires some kind of other protocol besides Truebit.
The query/response mechanism seems like a good place for the use of state channels. However, the current issue is the data availability problem around the timeout mechanism.
Ex: Using a state channel verifier makes a query, solver sends a response. Verifier claims solver never sent a response within the time frame (5 blocks). Solver has chance to prove they are indeed still playing. This fraud proof mechanism happens on-chain. Incentives dictate verifier pulls this trick every single query/response round because they want to see the solver lose. Then each round ends up being on-chain anyways.
Summary - In order to use state channels for query/response need to solve timeout fraud problem.
The text was updated successfully, but these errors were encountered: