On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi All, > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. > OP_SECURETHEBAG does more or less the same thing, but fixes malleability > issues and lifts the single output restriction to a known number of inputs > restriction. > > OP_CHECKOUTPUTSVERIFY had some issues with malleability of version and > locktime. OP_SECURETHEBAG commits to both of these values. > Can you elaborate a bit more on what the issues were? > OP_SECURETHEBAG also lifts the restriction that OP_CHECKOUTPUTSVERIFY had > to be spent as only a single input, and instead just commits to the number > of inputs. This allows for more flexibility, but keeps it easy to get the > same single output restriction. > > BIP: > https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki > Implementation: https://github.com/JeremyRubin/bitcoin/tree/secure_the_bag > > A particularly useful topic of discussion is how best to eliminate the > PUSHDATA and treat OP_SECURETHEBAG like a pushdata directly. I thought > about how the interpreter works and is implemented and couldn't come up > with something noninvasive. > I'm not a Core developer but from what I understand, I'd be inclined to to treat OP_SECURETHEBAG as with an immediate 32-byte parameter by modifying GetScriptOp to return the 32-byte parameter through pvchRet. bool GetScriptOp(CScriptBase::const_iterator& pc, CScriptBase::const_iterator end, opcodetype& opcodeRet, std::vector* pvchRet) { opcodeRet = OP_INVALIDOPCODE; if (pvchRet) pvchRet->clear(); if (pc >= end) return false; // Read instruction if (end - pc < 1) return false; unsigned int opcode = *pc++; // Immediate operand if (opcode <= OP_PUSHDATA4) { // ... } if (opcode == OP_SECURETHEBAG) { if (end - pc < 0 || (unsigned int)(end - pc) < 32) return false; if (pvchRet) pvchRet->assign(pc, pc + 32); pc += 32; } opcodeRet = static_cast(opcode); return true; } and go from there. Thank you for your review and discussion, > > Jeremy > > * Plus the name is better > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >