📅 Original date posted:2019-05-24
📝 Original message:Hi Russell,
Thanks for this detailed comparison. The COSHV BIP does include a brief
comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
detailed.
I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
clearly one of the more flexible options available and would enable a
multitude of new use cases.
When I originally presented my work on congestion control at Jan 2017
BPASE, I also discussed it as an option for covenants. Unfortunately I
think it may be on the edge of too powerful -- there are a lot of use cases
and implications from having a potentially recursive covenant. If you see
my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
non-computationally enumerable set of restrictions.
I think also from a developer point of view working with OP_COSHV is much
much simpler (maybe this can be abstracted) which will lead to increased
adoption. OP_COSHV also uses less per-block bandwidth which also makes it
preferable for a measure intended to decongest blocks. Do you know the
exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating
changes to taproot, can be a single byte. OP_COSHV also has less potential
to have a negative interaction with future opcodes we may want like
OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we
want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK
unless there's an exact specification which makes us confident we're
hitting all the points.
If the main complaint about OP_COSHV is that it peeks at surrounding data,
it's also possible to implement it more closely to a multi-byte pushdata
opcode or do the template optimization.
Lastly, as I have previously noted, OP_LEFT is probably safer to implement
than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/77a5aad9/attachment-0001.html>;
Jeremy [ARCHIVE] /
npub1q8…8qwta
2023-06-07 18:18:18
in reply to nevent1q…yca9
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 18:18:18Event JSON
{
"id": "6ca63f14754d608f7880df2764761ab729eb5f5653b60cd6ac8d8eb79d519da5",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686161898,
"kind": 1,
"tags": [
[
"e",
"3bdc2663aa3c63ce143c0d0e20e9bd2ecde5b81cd9fa06d3a2acdbe95190a0e6",
"",
"root"
],
[
"e",
"c7a2d258a098322db48b6969dcbc02e0c286b45a59e3afcda4f2ed5aec721d95",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2019-05-24\n📝 Original message:Hi Russell,\n\nThanks for this detailed comparison. The COSHV BIP does include a brief\ncomparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more\ndetailed.\n\n\nI think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's\nclearly one of the more flexible options available and would enable a\nmultitude of new use cases.\n\nWhen I originally presented my work on congestion control at Jan 2017\nBPASE, I also discussed it as an option for covenants. Unfortunately I\nthink it may be on the edge of too powerful -- there are a lot of use cases\nand implications from having a potentially recursive covenant. If you see\nmy response to Matt in the OP_COSHV BIP thread I classify it as enabling a\nnon-computationally enumerable set of restrictions.\n\nI think also from a developer point of view working with OP_COSHV is much\nmuch simpler (maybe this can be abstracted) which will lead to increased\nadoption. OP_COSHV also uses less per-block bandwidth which also makes it\npreferable for a measure intended to decongest blocks. Do you know the\nexact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating\nchanges to taproot, can be a single byte. OP_COSHV also has less potential\nto have a negative interaction with future opcodes we may want like\nOP_PUBKEYTWEAK. While we're getting to an exact spec for the features we\nwant in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK\nunless there's an exact specification which makes us confident we're\nhitting all the points.\n\nIf the main complaint about OP_COSHV is that it peeks at surrounding data,\nit's also possible to implement it more closely to a multi-byte pushdata\nopcode or do the template optimization.\n\nLastly, as I have previously noted, OP_LEFT is probably safer to implement\nthan OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190524/77a5aad9/attachment-0001.html\u003e",
"sig": "fb76ebc92f8e041c4db5fb684491967c307308aae13fae7e52e33def037f89ae2b1b7b697200d08c7b696801732e433843276fe79eb4ac7a56248f9e0abe034b"
}