4

Around the 5:00 timestamp in this talk, John Newbery states that running the concatenation of scriptPubKey and scriptSig is unsafe, since it can result in someone using a carefully crafted scriptSig in order to spend any output.

What would such a scriptSig look like?

Vojtěch Strnad
  • 8,292
  • 2
  • 12
  • 40
Cosmik Debris
  • 115
  • 4

1 Answers1

6

It was possible (see the infamous "1 RETURN bug") because the RETURN operand used to stop the execution of the Script. So simply pushing 1 in the scriptSig and RETURNing would make the execution of the catenated scriptSig || scriptPubKey successful no matter the content of the scriptPubKey.

Separating both certainly makes it easier to reason about and therefore be certain it's safe from this failure mode.

I initially posted this answer with an assertion that once the RETURN operand was fixed it was unclear how you would bypass the scriptPubKey. I didn't think hard enough! Actually you could simply include a PUSHDATA, which would interpret the scriptPubKey as a data array pushed on the stack, which would then make the execution successful since it would be casted to true as long as it's not all 0x00s.

So it's true that catenating the scriptSig and the scriptPubKey is always unsafe.

Antoine Poinsot
  • 8,334
  • 2
  • 17
  • 34
  • 1
    Thanks! I was under the impression that RETURN always implied the execution failed, since it is typically used to burn BTC. Is that what you meant by "fixing the RETURN operand"? – Cosmik Debris Aug 17 '23 at 15:42
  • 2
    @CosmikDebris Currently it is the case that OP_RETURN immediately marks the transaction invalid, but the the bug under discussion is exactly that its semantics used to simply be "stop execution" (which only resulted in failure if there was a false on top of the stack at that point). The practice of using OP_RETURN for burning funds came only years after this bug was fixed. – Pieter Wuille Aug 17 '23 at 16:02