Admit 1Hash block 474294 under a new omitted-parent-transaction rule

[deadmanoz]

Adds a missing_unconfirmed_parent evidence rule and the first block it admits: height 474294, 00000000000000000182acdf5657c93a0769dc6f9004047496b2e15efc6a4232, mined by 1Hash in July 2017.

Transaction 110 spends b11a78c6c61af1cb37586f639050d74b95c2b0fd525623b6cb6a4bb4fba46a0e:1. That parent transaction is not in the body and did not exist at the tip of 474293, so ConnectBlock fails with bad-txns-inputs-missingorspent. Both transactions confirmed in the same-height competitor 000000000000000000db2504327e272fe7658fac0dd0741f46b212256e500886.

The existing bad-txns-inputs-missingorspent checker (477115, 809478) only recognises in-block forward spends. 474294 has none, and a prevout absent from the body is what every valid block looks like, so absence alone cannot be the evidence.

What CI checks

CI accepts a missing_unconfirmed_parent record into the dataset only with a complete body, parent_kind canonical and coinbase context matching the record; an input whose parent transaction is not in the block; that transaction fetched or cached and verified by txid, containing the spent output; and Esplora /tx/{txid}/status currently reporting it confirmed in a different block at this height or later. Unconfirmed or 404 replies are not evidence and are not cached; a parent confirmed below this height is a normal spend.

CI does not rebuild the UTXO set at 474293 or replay ConnectBlock. It reasons from where the parent transaction is confirmed today: at or above the candidate's height means it was not in the chain below it, so its output did not exist when the block was mined. Two limits follow. A parent that confirmed earlier, was reorged out and re-confirmed at or above the candidate's height would pass, because the check sees only where the parent is confirmed now, not whether its output existed at the time. And the inference assumes the candidate extends the main chain. CI requires parent_kind to be canonical but does not verify that the previous block is on the main chain; that is established by review. Both are documented in docs/schema.md.

Changes

• ci/block_evidence.py, ci/prevouts.py, ci/sanity-check.py: predicate, shared raw-tx and /status fetch with {txid}.status.json caching, RULES entry requiring parent_kind, coinbase_height, coinbase_scriptsig_hex.
• data/invalid-blocks.jsonl and blocks/474294-…4232.bin (byte-identical to bitcoin-data/stale-blocks 2633e0e). Observations: merge-mining-research Namecoin child 349887 and the chainquery.com orphan listing in NStifter/mergedmonitor.
• Docs use "parent transaction" for the spent output's creator and "previous block" for the chain sense, since parent_kind and parent_mtp already use "parent" that way.
• Tests cover the height/hash boundaries, /status decoding, corrupt cache files and admission failure without cached confirmation.

Verification

python ci/sanity-check.py --fetch-prevouts (47 blocks, 6 block files) and python -m unittest discover -s ci -p 'test_*.py' (31 tests).

Related

bitcoin-data/stale-blocks#139 removes the invalid block from stale-blocks.

Original discussion: https://bitcointalk.org/index.php?topic=2041607.0.

[deadmanoz]

Drafting because I need to update the observation source in merge-mining-research so that the JSON entry has the correct "final" link (it needs to be demoted in that dataset to an error block)