📅 Original date posted:2022-02-08
📝 Original message:Rusty,
Note that this sort of design introduces recursive covenants similarly to
how I described above.
Whether that is an issue or not precluding this sort of design or not, I
defer to others.
Best,
Jeremy
On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> writes:
> > Given the overlap in functionality between CTV and ANYPREVOUT, I think it
> > makes sense to decompose their operations into their constituent pieces
> and
> > reassemble their behaviour programmatically. To this end, I'd like to
> > instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.
> >
> > OP_TXHASH would pop a txhash flag from the stack and compute a (tagged)
> > txhash in accordance with that flag, and push the resulting hash onto the
> > stack.
>
> It may be worth noting that OP_TXHASH can be further decomposed into
> OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).
>
> OP_TX would place the concatenated selected fields onto the stack
> (rather than hashing them) This is more compact for some tests
> (e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs
> "OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and also range
> testing (e.g amount less than X or greater than X, or less than 3 inputs).
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust set of TXHASH flags from the start. For example
> having
> > bits to control whether (1) the version is covered; (2) the locktime is
> > covered; (3) txids are covered; (4) sequence numbers are covered; (5)
> input
> > amounts are covered; (6) input scriptpubkeys are covered; (7) number of
> > inputs is covered; (8) output amounts are covered; (9) output
> scriptpubkeys
> > are covered; (10) number of outputs is covered; (11) the tapbranch is
> > covered; (12) the tapleaf is covered; (13) the opseparator value is
> > covered; (14) whether all, one, or no inputs are covered; (15) whether
> all,
> > one or no outputs are covered; (16) whether the one input position is
> > covered; (17) whether the one output position is covered; (18) whether
> the
> > sighash flags are covered or not (note: whether or not the sighash flags
> > are or are not covered must itself be covered). Possibly specifying
> which
> > input or output position is covered in the single case and whether the
> > position is relative to the input's position or is an absolute position.
>
> These easily map onto OP_TX, "(1) the version is pushed as u32, (2) the
> locktime is pushed as u32, ...".
>
> We might want to push SHA256() of scripts instead of scripts themselves,
> to reduce possibility of DoS.
>
> I suggest, also, that 14 (and similarly 15) be defined two bits:
> 00 - no inputs
> 01 - all inputs
> 10 - current input
> 11 - pop number from stack, fail if >= number of inputs or no stack elems.
>
> Cheers,
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220207/2a0a1a47/attachment.html>;
Jeremy Rubin [ARCHIVE] /
npub1xu…fzef0
2023-06-07 23:03:23
in reply to nevent1q…jpsy
Author Public Key
npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0Published at
2023-06-07 23:03:23Event JSON
{
"id": "a8ff0aca5d8cdfc57eed22ae301badba1f6a51835d84747a2bee279a28ed0d81",
"pubkey": "372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a",
"created_at": 1686179003,
"kind": 1,
"tags": [
[
"e",
"452992012bb05a59b05452f7bb44645a0965d1a20372b47355e5d904fc3bc381",
"",
"root"
],
[
"e",
"17567c49771c456f4bc19cbc08f60177cfb56e7f174acad370a1273e183f4381",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2022-02-08\n📝 Original message:Rusty,\n\nNote that this sort of design introduces recursive covenants similarly to\nhow I described above.\n\nWhether that is an issue or not precluding this sort of design or not, I\ndefer to others.\n\nBest,\n\nJeremy\n\n\nOn Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Russell O'Connor via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e writes:\n\u003e \u003e Given the overlap in functionality between CTV and ANYPREVOUT, I think it\n\u003e \u003e makes sense to decompose their operations into their constituent pieces\n\u003e and\n\u003e \u003e reassemble their behaviour programmatically. To this end, I'd like to\n\u003e \u003e instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.\n\u003e \u003e\n\u003e \u003e OP_TXHASH would pop a txhash flag from the stack and compute a (tagged)\n\u003e \u003e txhash in accordance with that flag, and push the resulting hash onto the\n\u003e \u003e stack.\n\u003e\n\u003e It may be worth noting that OP_TXHASH can be further decomposed into\n\u003e OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).\n\u003e\n\u003e OP_TX would place the concatenated selected fields onto the stack\n\u003e (rather than hashing them) This is more compact for some tests\n\u003e (e.g. testing tx version for 2 is \"OP_TX(version) 1 OP_EQUALS\" vs\n\u003e \"OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS\"), and also range\n\u003e testing (e.g amount less than X or greater than X, or less than 3 inputs).\n\u003e\n\u003e \u003e I believe the difficulties with upgrading TXHASH can be mitigated by\n\u003e \u003e designing a robust set of TXHASH flags from the start. For example\n\u003e having\n\u003e \u003e bits to control whether (1) the version is covered; (2) the locktime is\n\u003e \u003e covered; (3) txids are covered; (4) sequence numbers are covered; (5)\n\u003e input\n\u003e \u003e amounts are covered; (6) input scriptpubkeys are covered; (7) number of\n\u003e \u003e inputs is covered; (8) output amounts are covered; (9) output\n\u003e scriptpubkeys\n\u003e \u003e are covered; (10) number of outputs is covered; (11) the tapbranch is\n\u003e \u003e covered; (12) the tapleaf is covered; (13) the opseparator value is\n\u003e \u003e covered; (14) whether all, one, or no inputs are covered; (15) whether\n\u003e all,\n\u003e \u003e one or no outputs are covered; (16) whether the one input position is\n\u003e \u003e covered; (17) whether the one output position is covered; (18) whether\n\u003e the\n\u003e \u003e sighash flags are covered or not (note: whether or not the sighash flags\n\u003e \u003e are or are not covered must itself be covered). Possibly specifying\n\u003e which\n\u003e \u003e input or output position is covered in the single case and whether the\n\u003e \u003e position is relative to the input's position or is an absolute position.\n\u003e\n\u003e These easily map onto OP_TX, \"(1) the version is pushed as u32, (2) the\n\u003e locktime is pushed as u32, ...\".\n\u003e\n\u003e We might want to push SHA256() of scripts instead of scripts themselves,\n\u003e to reduce possibility of DoS.\n\u003e\n\u003e I suggest, also, that 14 (and similarly 15) be defined two bits:\n\u003e 00 - no inputs\n\u003e 01 - all inputs\n\u003e 10 - current input\n\u003e 11 - pop number from stack, fail if \u003e= number of inputs or no stack elems.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220207/2a0a1a47/attachment.html\u003e",
"sig": "3d3ec89aa1b640dbfcef0d93721433df2ad4503eb6c6722a01f766854d37a12f2edf8356bfb2cef458bf1352e24bffb7e62180dafd3f4ad108f73b09d3706756"
}