Hi all, I apologize for a couple of oversights in my last e-mail.
The first is that m_B can't be committed as-is in the contract's embedded data, with the current semantics of OP_COCV, which only allows 32-byte values. A solution could be to store its hash SHA256(m_B), instead. (I didn't test the Scripts, so there could be other bugs − hopefully the general idea is clear, anyway) On Mon, 1 May 2023 at 15:11, Salvatore Ingala <salvatore.ing...@gmail.com> wrote: > If the internal_pubkey is a musig-aggregated key of Alice and Bob, > the game can be settled entirely offline after the first transaction. > Simply, Bob communicates his move to Alice, Alice reveals her move to > Bob, and they can settle the bet. The game would be played without > any script being executed, therefore all transactions could look like > any other P2TR, with the only possible fingerprinting being due to the > input amounts. > This is incomplete: Alice can't trust Bob by revealing her move, as he could then cheat on-chain and play a different move. The fix should be straightforward, after adding the requirement that the internal pubkey of [S1] is a musig2 of both players. After Bob reveals his move (say, Rock), Alice will only agree to continue the game off-chain if Bob pre-signs transactions for the state [S1] (where m_B = Paper, and m_B = Scissors) that send all the money to Alice. This guarantees that a cheating Bob is punished. Best, Salvatore Ingala
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
