{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-06\n📝 Original message:Good morning Peter, Jeremy, and lists,\n\n\u003e On Fri, Oct 04, 2019 at 11:40:53AM -0700, Jeremy wrote:\n\u003e\n\u003e \u003e Interesting point.\n\u003e \u003e The script is under your control, so you should be able to ensure that you\n\u003e \u003e are always using a correctly constructed midstate, e.g., something like:\n\u003e \u003e scriptPubKey: \u003c-1\u003e OP_SHA256STREAM DEPTH OP_SHA256STREAM \u003c-2\u003e\n\u003e \u003e OP_SHA256STREAM\n\u003e \u003e \u003chash\u003e OP_EQUALVERIFY\n\u003e \u003e would hash all the elements on the stack and compare to a known hash.\n\u003e \u003e How is that sort of thing weak to midstateattacks?\n\u003e\n\u003e Obviously with care you can get the computation right. But at that point what's\n\u003e the actual advantage over OP_CAT?\n\u003e\n\u003e We're limited by the size of the script anyway; if the OP_CAT output size limit\n\u003e is comparable to that for almost anything you could use SHA256STREAM on you\n\u003e could just as easily use OP_CAT, followed by a single OP_SHA256.\n\nTheoretically, `OP_CAT` is less efficient.\n\nIn cases where the memory area used to back the data cannot be resized, new backing memory must be allocated elsewhere and the existing data copied.\nThis leads to possible O( n^2 ) behavior for `OP_CAT` (degenerate case where we add 1 byte per `OP_CAT` and each time find that the memory area currently in use is exactly fitting the data and cannot be resized in-place).\n\n`OP_SHASTREAM` would not require new allocations once the stream state is in place and would not require any copying.\n\n\nThis may be relevant in considering the cost of executing `OP_CAT`.\n\nAdmittedly a sufficiently-limited  maximum `OP_CAT` output would be helpful in reducing the worst-case `OP_CAT` behavior.\nThe question is what limit would be reasonable.\n64 bytes feels too small if one considers Merkle tree proofs, due to mentioned issues of lack of typechecking.\n\n\nRegards,\nZmnSCPxj\n\n\n\u003e\n\u003e --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n\u003e\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}