Salvatore Ingala [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-01 🗒️ Summary of this message: The email ...
📅 Original date posted:2023-05-01
🗒️ Summary of this message: The email discusses oversights in a previous email regarding a contract's embedded data and suggests a solution to store a hash instead. It also proposes a fix for a potential cheating scenario in a game played offline.
📝 Original message: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.ingala at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230501/a850251d/attachment.html>;
🗒️ Summary of this message: The email discusses oversights in a previous email regarding a contract's embedded data and suggests a solution to store a hash instead. It also proposes a fix for a potential cheating scenario in a game played offline.
📝 Original message: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.ingala at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230501/a850251d/attachment.html>;