This bug was found when I try to use fundrawtransaction to add inputs to an Atomic Swap TX. There are a lot of opcodes in the TX, which look like:
"vout": [
{
"value": 100.00000000,
"n": 0,
"scriptPubKey": {
"asm": "OP_IF 2 032f3c19a70214f1cc4adb09f9c2fbd97b42c739003b6d7f45b8d1387566fd978b 02e8cc90cad5436865e869bc78bf06af0a662c0542e313be1a4392ce905b75d7bc 2 OP_CHECKMULTISIG OP_ELSE 2485 OP_CHECKLOCKTIMEVERIFY OP_DROP 039787806b54b82d29de040ff7009f5afcbd56ee4f7fb863557eca57cad4d71a43 OP_CHECKSIG OP_ENDIF",
...
}
...
]
These opcodes are not considered in fundrawtransaction when calculating nBytes. So nBytes and the corresponding nFeeNeeded would get a relatively low value.
But when I use sendrawtransaction to send the TX. It will take these opcodes into consideration when calculating nSize. nSize has a relatively high value, so the TX can't pass the relay fee check and sendrawtransaction returns "min relay fee not met".
This is the first time I know the opcodes should be considered in the calculation of transaction fee. But when I go through all the calls of function GetVirtualTransactionSize, I find some pass nSigOpCost into it but some don't. It's weird and I can't figure it out.
