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.
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<unsigned char>* 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<opcodetype>(opcode);
return true;
}
and go from there.
Thank you for your review and discussion,
* Plus the name is better
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev