Optional fields are required to make bitcoin block, causing errors

[MicaiahReid]

Describe the bug
On this line when standardizing a bitcoin block, the prevout field for a bitcoin transaction is required, and Chainhook throws an error if the field is missing. However, prevout is an optional field, and many transaction inputs don't include it.

This causes many blocks to be skipped and will definitely lead to missed predicate triggers.

To Reproduce
Steps to reproduce the behavior:

1. Create and run the following predicate, and see that the transaction is not found.

{
  "uuid": "1",
  "name": "Hello Ordinals",
  "chain": "bitcoin",
  "version": 1,
  "networks": {
    "mainnet": {
      "start_block": 801221,
      "end_block": 801221,
      "if_this": {
        "scope": "txid",
        "equals": "0x55c86631e9b08b817e6ebac00b9818d1fd49e0a7d6c00429b6e364d3ef845920"
      },
      "then_that": {
        "file_append": {
          "path": "results/transaction-file-result.json"
        }
      }
    }
  }
}

Expected behavior
A bitcoin block is build event when optional transaction inputs are missing.

[qustavo]

AFAICT prevout is used to compute the fee

chainhook/components/chainhook-sdk/src/indexer/bitcoin/mod.rs

Line 493 in 499b86c

sats_in += prevout.value.to_sat();

and

chainhook/components/chainhook-sdk/src/indexer/bitcoin/mod.rs

Line 536 in 499b86c

fee: sats_in.saturating_sub(sats_out),

.

I don't see where these are being used apart from just being set:

chainhook/components/chainhook-sdk/src/indexer/bitcoin/mod.rs

Lines 499 to 500 in 499b86c

	block_height: prevout.height,
	value: prevout.value.to_sat(),

Since fees can be extracted from the block's RPC response, is removing prevout a possible solution here?

[MicaiahReid]

We actually found that it was the is_coinbase function that's broken. This PR will fix it.

All transactions except coinbase transactions must have a prevout field, so it's okay to require them.

[qustavo]

that makes sense!

[qustavo]

@MicaiahReid I noticed that the prevout field has been added to bitcoind on version v23.0.0, meaning that previous versions will not have such a field populated. Would it make sense to validate the node's version upon chainhook start and fail if a given version constraint is not met?

[MicaiahReid]

@qustavo great find. There's additional discussion here: #391 (comment)

[MicaiahReid]

It looks like this occurs when using an outdated version of bitcoind. We will be specifying the requirement to use bitcoind v24+ in #405. Closing this issue as not planned.