Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-16 📝 Original message:I agree this is an ...
📅 Original date posted:2016-08-16
📝 Original message:I agree this is an interesting area of transaction malleability to still
consider in the future, and minimization of these areas of malleability
with regards to its impact on the p2p network should be easy to resolve
and (hopefully) well-understood by script writers in the future.
On Tue, Aug 16, 2016 at 12:43:32PM -0700, Peter Todd via bitcoin-dev wrote:
> Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode
> that fails unless the top item on the stack is a minimally encoded true or
> false value, to allow script writers to opt into this behavior; it's not always
> ideal.
I think the biggest value of the proposed BIP behavior is that the cost
is lower for "doing it right" to create script enforcement of OP_TRUE or
OP_FALSE. It is already possible to enforce with 2 bytes pushing OP_TRUE
and then OP_EQUAL. Creating an "OP_CHECKBOOLVERIFY" definitely achieves
the same result, but at a 1-byte (insetad of 2-byte) cost to "do it
right", so there is the same incentive to save on the byte and push
potential DoS costs onto the network -- whereas enforcing OP_TRUE byte
in OP_IF would create costs for those who want to evaluate pushdata, so
that has to be explicitly opt-in from an optimization/convenience
standpoint.
--
Joseph Poon
Published at
2023-06-07 17:52:56Event JSON
{
"id": "657e653d161da25e1254fad9e4c3c62d60ea34c693802f968cf9e6ef9d8ce440",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686160376,
"kind": 1,
"tags": [
[
"e",
"9284d48ee3ec0986e743af41281b218e681b340835d80de299ea9e9d68940884",
"",
"root"
],
[
"e",
"52beeb1dcddd5f15997ee77ccac7088927ca68c2dd4a063e618d745961dc3a1f",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2016-08-16\n📝 Original message:I agree this is an interesting area of transaction malleability to still\nconsider in the future, and minimization of these areas of malleability\nwith regards to its impact on the p2p network should be easy to resolve\nand (hopefully) well-understood by script writers in the future.\n\nOn Tue, Aug 16, 2016 at 12:43:32PM -0700, Peter Todd via bitcoin-dev wrote:\n\u003e Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode\n\u003e that fails unless the top item on the stack is a minimally encoded true or\n\u003e false value, to allow script writers to opt into this behavior; it's not always\n\u003e ideal.\n\nI think the biggest value of the proposed BIP behavior is that the cost\nis lower for \"doing it right\" to create script enforcement of OP_TRUE or\nOP_FALSE. It is already possible to enforce with 2 bytes pushing OP_TRUE\nand then OP_EQUAL. Creating an \"OP_CHECKBOOLVERIFY\" definitely achieves\nthe same result, but at a 1-byte (insetad of 2-byte) cost to \"do it\nright\", so there is the same incentive to save on the byte and push\npotential DoS costs onto the network -- whereas enforcing OP_TRUE byte\nin OP_IF would create costs for those who want to evaluate pushdata, so\nthat has to be explicitly opt-in from an optimization/convenience\nstandpoint.\n\n-- \nJoseph Poon",
"sig": "bfe38390c3e6c23e147a1bfdf9233cc4c1d42aad74143bbf24627ffaa01ffad25aff4cc927e34da1ddcc31864fa667493b84fec37b72c1170866c0b2b500f185"
}