📅 Original date posted:2023-08-09
🗒️ Summary of this message: The author thanks Johan for their comments and implementation. They discuss the ordering of parameters and the use cases for the deferred output amount check in CCV.
📝 Original message:
Hi Johan,
Thanks a lot for the comments, and the independent implementation!
> - For the opcode parameter ordering, it feels unnatural for the two
> tweaks (data, taptree) to be separated by the internal key. A more
> natural ordering of parameters IMO would be (of course this is all
> subjective):
> <data> <taptree> <internalkey> <index> <flags> OP_CCV.
>
> If you disagree, I would love some rationale for the ordering you
> chose! (looks like you also changed it again after your last post?).
The main concern for the reordering was to put <data> at the bottom,
as that's typically passed via the witness stack.
I put the <index> right next, as I suspect there are use cases for
specifying via the witness what is the input index where a certain
(CCV-encumbered) UTXO is to be found, or which output should funds
be sent to, instead of hard-coding this in the script. This might
help in designing contracts that are more flexible in the way they
are spent, for example by allowing batching their transactions.
Instead, I expect the other parameters to almost always be hardcoded,
or propagated from the current input with the <-1> special values.
I agree that your ordering is more aesthetically pleasing, though.
> I'm wondering what other use cases you had in mind for the deferred
> output amount check? Maybe I have missed something, but if not it
> would perhaps be better to leave out the amount preservation check, or
> go the extra mile and propose a more powerful amount introspection
> machinery.
Yes, the deferred output amount check is not enough for coinpools;
however, it comes at no cost if we have a <flags> parameter anyway,
as OP_2 (value for CCV_IGNORE_OUTPUT_AMOUNT) is a single byte opcode.
The intent of preserving amounts for many-to-one contracts (vaults),
or the one-to-one cases (channels, any 2-party contract, etc.) seems
common enough to deserve 1 bit in the flags, IMHO.
Efforts to define and add explicit introspection to cover your
(exciting!) use cases can proceed independently, but I don't think
they would nullify the advantages of this (optional) feature of CCV.
Best,
Salvatore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230809/72053c9c/attachment.html>;
Salvatore Ingala [ARCHIVE] /
npub1lp…c74n4
2023-08-09 16:03:59
in reply to nevent1q…j8v0
Author Public Key
npub1lpkmxpl2zhk0w30vtdz7s64ml9644k785eggmjsjgs7wman3szzqac74n4Published at
2023-08-09 16:03:59Event JSON
{
"id": "74222f9a3e673a987e2905d4e80a8ffd7b650c41fe129c7f06047c578308e3c9",
"pubkey": "f86db307ea15ecf745ec5b45e86abbf9755adbc7a6508dca12443cedf6718084",
"created_at": 1691597039,
"kind": 1,
"tags": [
[
"e",
"86649676ae3ff05a6e718ccf3b301e4e0e000c38b8f97ecfab084b85db23c5a3",
"",
"root"
],
[
"e",
"da4cf749fd7d8e5c46357d9c23347b1b73ebc5d44e646b2e25970e99c569866d",
"",
"reply"
],
[
"p",
"0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f"
]
],
"content": "📅 Original date posted:2023-08-09\n🗒️ Summary of this message: The author thanks Johan for their comments and implementation. They discuss the ordering of parameters and the use cases for the deferred output amount check in CCV.\n📝 Original message:\nHi Johan,\n\nThanks a lot for the comments, and the independent implementation!\n\n\u003e - For the opcode parameter ordering, it feels unnatural for the two\n\u003e tweaks (data, taptree) to be separated by the internal key. A more\n\u003e natural ordering of parameters IMO would be (of course this is all\n\u003e subjective):\n\u003e \u003cdata\u003e \u003ctaptree\u003e \u003cinternalkey\u003e \u003cindex\u003e \u003cflags\u003e OP_CCV.\n\u003e\n\u003e If you disagree, I would love some rationale for the ordering you\n\u003e chose! (looks like you also changed it again after your last post?).\n\nThe main concern for the reordering was to put \u003cdata\u003e at the bottom,\nas that's typically passed via the witness stack.\n\nI put the \u003cindex\u003e right next, as I suspect there are use cases for\nspecifying via the witness what is the input index where a certain\n(CCV-encumbered) UTXO is to be found, or which output should funds\nbe sent to, instead of hard-coding this in the script. This might\nhelp in designing contracts that are more flexible in the way they\nare spent, for example by allowing batching their transactions.\n\nInstead, I expect the other parameters to almost always be hardcoded,\nor propagated from the current input with the \u003c-1\u003e special values.\n\nI agree that your ordering is more aesthetically pleasing, though.\n\n\u003e I'm wondering what other use cases you had in mind for the deferred\n\u003e output amount check? Maybe I have missed something, but if not it\n\u003e would perhaps be better to leave out the amount preservation check, or\n\u003e go the extra mile and propose a more powerful amount introspection\n\u003e machinery.\n\nYes, the deferred output amount check is not enough for coinpools;\nhowever, it comes at no cost if we have a \u003cflags\u003e parameter anyway,\nas OP_2 (value for CCV_IGNORE_OUTPUT_AMOUNT) is a single byte opcode.\n\nThe intent of preserving amounts for many-to-one contracts (vaults),\nor the one-to-one cases (channels, any 2-party contract, etc.) seems\ncommon enough to deserve 1 bit in the flags, IMHO.\nEfforts to define and add explicit introspection to cover your\n(exciting!) use cases can proceed independently, but I don't think\nthey would nullify the advantages of this (optional) feature of CCV.\n\nBest,\nSalvatore\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230809/72053c9c/attachment.html\u003e",
"sig": "7568f16daf6661f295f468c67075457db88308fa51d40c63f0c3d1b10358073fc9bc01c92ff7022522cd7cb57006afe806ecc667d58b75d5d7f4fb489df2681a"
}