📅 Original date posted:2023-05-04
🗒️ Summary of this message: The construct allows access to embedded data of inputs and outputs, and enforcement of output keys and static taptrees. Merkle tree inclusion/exclusion in script could be used for efficient proof.
📝 Original message: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 at 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.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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-07 23:21:08
in reply to nevent1q…d3ta
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-07 23:21:08Event JSON
{
"id": "e4759403f09d49d816c83ee000d0c7d5b47acefca1972d81a10c2d74d6e02a89",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686180068,
"kind": 1,
"tags": [
[
"e",
"500d1583685224e78093a7b1e94b55fe48ea9754e88e656744e0fa5e949018f0",
"",
"root"
],
[
"e",
"8cf599608659079b0227e57be52bdef473e5a35653c0ae0fcc48cfbd6e9aa922",
"",
"reply"
],
[
"p",
"f86db307ea15ecf745ec5b45e86abbf9755adbc7a6508dca12443cedf6718084"
]
],
"content": "📅 Original date posted:2023-05-04\n🗒️ Summary of this message: The construct allows access to embedded data of inputs and outputs, and enforcement of output keys and static taptrees. Merkle tree inclusion/exclusion in script could be used for efficient proof.\n📝 Original message:Thank you for the example.\n\nIt sounds like we can generalize the description of the construct to:\nAccess to (the hash of) embedded data of inputs and outputs, and the\nenforcement of output keys and (static) taptrees. In other words, as\nlong as you can dynamically compute the output embedded data in\nScript, you can enforce more or less anything (since you can make the\noutput script enforce presenting a witness \"satisfying\" the embedded\ndata).\n\nDoes that sound about right?\n\nFor instance, I believe you could simulate coin pools pretty easily:\nCommit to the set of pubkeys and amounts owned by the participants in\nthe pool, and an output taptree where each participant has their own\nspending path. Now, to exit the pool unilaterally, the participant\nmust present a proof that their pubkey+amount is committed to in the\ninput and an output where it is no longer committed.\n\nA question that arises is how one would efficiently (in Script) prove\nthe inclusion/exclusion of the data in the commitment. One could\nnaively hash all the data twice during script execution (once for the\ninput, once for the output), but that is costly. It would be natural\nto show merkle tree inclusion/exclusion in script, but perhaps there\nare more efficient ways to prove it?\n\n- Johan\n\n\nOn Tue, May 2, 2023 at 12:44 AM Salvatore Ingala via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Hi all,\n\u003e\n\u003e I apologize for a couple of oversights in my last e-mail.\n\u003e\n\u003e The first is that m_B can't be committed as-is in the contract's\n\u003e embedded data, with the current semantics of OP_COCV, which\n\u003e only allows 32-byte values. A solution could be to store its\n\u003e hash SHA256(m_B), instead.\n\u003e\n\u003e (I didn't test the Scripts, so there could be other bugs − hopefully the\n\u003e general idea is clear, anyway)\n\u003e\n\u003e On Mon, 1 May 2023 at 15:11, Salvatore Ingala \u003csalvatore.ingala at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e If the internal_pubkey is a musig-aggregated key of Alice and Bob,\n\u003e\u003e the game can be settled entirely offline after the first transaction.\n\u003e\u003e Simply, Bob communicates his move to Alice, Alice reveals her move to\n\u003e\u003e Bob, and they can settle the bet. The game would be played without\n\u003e\u003e any script being executed, therefore all transactions could look like\n\u003e\u003e any other P2TR, with the only possible fingerprinting being due to the\n\u003e\u003e input amounts.\n\u003e\n\u003e\n\u003e This is incomplete: Alice can't trust Bob by revealing her move, as\n\u003e he could then cheat on-chain and play a different move.\n\u003e\n\u003e The fix should be straightforward, after adding the requirement that the\n\u003e internal pubkey of [S1] is a musig2 of both players.\n\u003e After Bob reveals his move (say, Rock), Alice will only agree to continue\n\u003e the game off-chain if Bob pre-signs transactions for the state [S1] (where\n\u003e m_B = Paper, and m_B = Scissors) that send all the money to Alice.\n\u003e This guarantees that a cheating Bob is punished.\n\u003e\n\u003e Best,\n\u003e Salvatore Ingala\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "8029b56c273b2eae617494a6745e00d67e4153629551f4c5e45a0ac6cc1c3385d5eddce3a1bf32452747582f77fc3259a0b4a554b7773408b5a0de6a57d7bfc9"
}