Thank you for the example. It sounds like we can generalize the description of the construct to: Access to (the hash of) embedded data of inputs and outputs, and the enforcement of output keys and (static) taptrees. In other words, as long as you can dynamically compute the output embedded data in Script, you can enforce more or less anything (since you can make the output script enforce presenting a witness "satisfying" the embedded data).
Does that sound about right? For instance, I believe you could simulate coin pools pretty easily: Commit to the set of pubkeys and amounts owned by the participants in the pool, and an output taptree where each participant has their own spending path. Now, to exit the pool unilaterally, the participant must present a proof that their pubkey+amount is committed to in the input and an output where it is no longer committed. A question that arises is how one would efficiently (in Script) prove the inclusion/exclusion of the data in the commitment. One could naively hash all the data twice during script execution (once for the input, once for the output), but that is costly. It would be natural to show merkle tree inclusion/exclusion in script, but perhaps there are more efficient ways to prove it? - Johan On Tue, May 2, 2023 at 12:44 AM Salvatore Ingala via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
