Sanity check: is it possible to have two CHECKSIG operations in a single scriptPubKey that both succeed? It seems like it requires the two signatures to sign each other.

@NickODell I've never looked at it in any depth, but SIGHASH_ALL signs the outputs, not the inputs of a transaction otherwise you'd always have a recursive problem.

If you haven't some better insight from someone else I'll look at it later, the transaction signing in Bitcoin is fairly complicated and buggy in weird ways.

github.com/bitcoin/bitcoin/blob/…

To me, it looks like it only drops the signature it's currently checking, and not the signature of a past or future CHECKSIG.

Ah, ok. The input is removed while serializing scriptCode in CTransactionSignatureSerializer

github.com/bitcoin/bitcoin/blob/…

Not sure why it also does that replacement in EvalScript, then.

@NickODell Some bits like OP_CODESEPARATOR are historical (and the behavior removed because it was exploitable), some bits like SIGHASH_SINGLE are just plain wrong, and a lot of the transaction stuff is just strange for reasons only Satoshi can possibly explain. There's a diagram with some of the steps of SIGHASH_ALL on the wiki if that clears anything up for you. en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png

At one point someone posited the concept that Satoshi didn't want to discriminate between big and little endian byte order, which is why in the transaction binary format both are used seemingly at random.