verification: skip checking input scripts

[ellemouton]

In this commit, the checks for input script pub keys is removed since the function used to reconstruct script pub keys from witness data currently does not take taproot outputs into consideration and so is producing the wrong script pubkeys which then causes the verification to fail. This code can be put back once the ComputeScriptPubKey function takes taproot into account.

off the top of my head, I think that the ComputeScriptPubKey function might need to be changed to return a set of options since i think sometimes we wont be able to tell the difference between a P2WPKH, P2TR key path with annex, P2TR script path.

[chappjc]

off the top of my head, I think that the ComputeScriptPubKey function might need to be changed to return a set of options since i think sometimes we wont be able to tell the difference between a P2WPKH, P2TR key path with annex, P2TR script path.

It might not be possible to tell the difference between v0 P2WSH and P2WPKH either since it's possible to have a 33-byte redeem script with one other item in the witness stack, so that it will look like a keyhash script when it's really a scripthash script.

More generally though, given that the witness script version is in the output script, which this is trying to find, I don't know how feasible it is do go from witness data -> pkscript.

[Roasbeef]

I'm curious what can really be done with an input's witness data given that the witness version is not known without the script itself, and future versions could have a witness stack data pattern that matches multiple witness output script versions.

Yeah it's difficult, the heursitic was mean to be moreso on a best effort basis to ensure that spends we cared about (p2wsh multi-sig mainly in the case of LN) were properly included in the filter. Re that single stack element, it's possible that we pattern match further by asserting it's a pubkey in the new taproot format. However not clear where that ends as it becomes a game a wack-a-mole.

What I think we really need here is a new p2p message that allows nodes to fetch the undo data, which would include the prev pkScripts (we can verify this is actually legit), and use that to assert the validity of a filter.

In the short term, I think this PR is the right move, but maybe we keep the code in tact and instead just log instead of erroring out? Want to think of a way we can still retain the extra validation in the short term...

[ellemouton]

Want to think of a way we can still retain the extra validation in the short term

One thing i can think of is: if we downloaded this block cause it matched on one of our inputs, we can pass these inputs into the function so that if we get to a tx that spends one of our txid:vout's, we defs will know the scriptPubKey that should match against the filter. No guessing game in that case about what the correct scriptPubKey for the witness should be.

[sipa]

I'm not enough up to date to know if this is relevant, but:

BIP341 was designed to permit some recognizability of what type a spend is without seeing the UTXO being spent.

• If the witness stack is a single item, of 64 or 65 bytes long, it could be either a P2TR key path spend, or a (very strange anyone-can-spend) P2WSH spend with no script arguments.
• If the last witness stack item starts with 0x50, it is an annex for a P2TR key or script path spend (depending on what comes before). P2WPKH or P2WSH spends cannot start with a 0x50 (because opcode 0x50 would be invalid, and P2WPKH ends with a pubkey so must be 0x02 or 0x03, or 0x04/0x06/0x07 for non-standard ones).
• If the last witness stack item starts with 0xc0 or 0xc1, it is a BIP342 P2TR script path. For the same reason as with 0x50, P2WPKH or P2WSH spends cannot have these bytes there.
• If the last witness stack item starts with a valid script opcode (not an opcode that immediately invalidates execution), it is a P2WPKH or P2WSH spend (P2WPKH only possible if exactly two elements, and the last is 33 bytes starting with 0x02,0x03,0x04,0x06,0x07).
• Otherwise, it is a P2TR script path spend with unknown leaf version.