š
Original date posted:2021-07-04
š Original message:I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
to the txdata? When might you use this?
And yes -- "Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to
follow the semantics from bip340-342 when witness program is v1." is a bit
light on detail for what the BIP would end up looking like. If you're able
to open up the design process a bit more on that it would be good as I
think there are some topics worth discussing at large before things proceed
with Elements (assuming feature compatibility remains a goal).
The non-prehashed argument seems OK (at the cost of an extra byte...) but
are there specific applications for !=32 arguments? I can't think of a
particular one beyond perhaps efficiency. Can we safely use 0-520 byte
arguments?
Also do you have thoughts on the other questions i posed above? E.g.
splitting R/S could be helpful w/o CAT.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor <roconnor at blockstream.com>
wrote:
> There is one line written at
> https://github.com/ElementsProject/elements/pull/949/files#r660130155.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210704/0301926c/attachment.html>;
Jeremy [ARCHIVE] /
npub1q8ā¦8qwta
2023-06-07 22:56:17
in reply to nevent1qā¦9u8t
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 22:56:17Event JSON
{
"id": "d07f15b426d9aebd2d4e0d002bb211c1c3b10f3da9a1dbc9cea6294f60437f11",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686178577,
"kind": 1,
"tags": [
[
"e",
"e305e1323b30b871a30d4051fe1bdd51042801c383eb2b02a7d24b80f15d4a24",
"",
"root"
],
[
"e",
"0ad3ebba78a8fb11590194c070d66d10500b1736d4f234078d714df5b3a03f82",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "š
Original date posted:2021-07-04\nš Original message:I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound\nto the txdata? When might you use this?\n\nAnd yes -- \"Add OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY to\nfollow the semantics from bip340-342 when witness program is v1.\" is a bit\nlight on detail for what the BIP would end up looking like. If you're able\nto open up the design process a bit more on that it would be good as I\nthink there are some topics worth discussing at large before things proceed\nwith Elements (assuming feature compatibility remains a goal).\n\nThe non-prehashed argument seems OK (at the cost of an extra byte...) but\nare there specific applications for !=32 arguments? I can't think of a\nparticular one beyond perhaps efficiency. Can we safely use 0-520 byte\narguments?\n\nAlso do you have thoughts on the other questions i posed above? E.g.\nsplitting R/S could be helpful w/o CAT.\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Sat, Jul 3, 2021 at 1:13 PM Russell O'Connor \u003croconnor at blockstream.com\u003e\nwrote:\n\n\u003e There is one line written at\n\u003e https://github.com/ElementsProject/elements/pull/949/files#r660130155.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210704/0301926c/attachment.html\u003e",
"sig": "73e4ecdb6ec9de056b03c313b83df7a2f08185bd7855aebdfc2b66a2c1a6bcb7c9a5ac09b19a4e79bc24d4f8470aa38d85db55cc92c4de8b5142a9178701da5f"
}