{"type":"rich","version":"1.0","author_name":"npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8t","author_url":"https://nostr.ae/npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8t","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-05-19\n📝 Original message:AFAICT, re-enabling these old OP-codes would require a hardfork.\n\nIf we had SegWit enabled, we could via a soft fork allocate new OP-codes\nfor the same functionality (by introducing a new version of Script).\nI believe the Elements alpha project has been experimenting with\nre-enabling old OP-codes: https://elementsproject.org/elements/opcodes/\n\n2017-05-19 8:07 GMT+02:00 Mark Boldyrev via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e Back in 2010, there was a bug found in Core which allowed\n\u003e denial-of-service attacks due to the software crashing on some machines\n\u003e while executing a script - see CVE-2010-537.\n\u003e I believe the removed (\"disabled\") opcodes should be re-introduced along\n\u003e with a standardized behavior definition.\n\u003e For example, when execution of an opcode results in an arithmetic error,\n\u003e such as OP_DIV with a zero divisor, the script should exit and fail.\n\u003e The string splice opcodes should also check their arguments for\n\u003e correctness, etc.\n\u003e\n\u003e These opcodes would enhance the flexibility of scripts and allow\n\u003e sophisticated native smart contracts to be created.\n\u003e\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170519/9dd5d326/attachment.html\u003e"}