Make explicit that the child of LVH is INVALID (#254)

* Make explicit that the child of LVH is INVALID

* Update src/engine/specification.md

Co-authored-by: Mikhail Kalinin <noblesse.knight@gmail.com>

* add null option for validhash

* specify that null is only allowed when the block does not exist

* Andrew+Misha's comment

Co-authored-by: Mikhail Kalinin <noblesse.knight@gmail.com>

src/engine/specification.md

@@ -219,8 +219,13 @@ Payload validation process consists of validating a payload with respect to the
 
 3. Client software **MUST** validate a payload according to the block header and execution environment rule set with modifications to these rule sets defined in the [Block Validity](https://eips.ethereum.org/EIPS/eip-3675#block-validity) section of [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675#specification):
   * If validation succeeds, the response **MUST** contain `{status: VALID, latestValidHash: payload.blockHash}`
-  * If validation fails, the response **MUST** contain `{status: INVALID, latestValidHash: validHash}` where `validHash` is the block hash of the most recent *valid* ancestor of the invalid payload. That is, the valid ancestor of the payload with the highest `blockNumber`
-  * If the most recent valid ancestor is a PoW block, `latestValidHash` **MUST** be set to `0x0000000000000000000000000000000000000000000000000000000000000000`
+  * If validation fails, the response **MUST** contain `{status: INVALID, latestValidHash: validHash}` where `validHash` **MUST** be:
+    - The block hash of the ancestor of the invalid payload satisfying the following two conditions:
+      - It is fully validated and deemed `VALID`
+      - Any other ancestor of the invalid payload with a higher `blockNumber` is `INVALID`
+    - `0x0000000000000000000000000000000000000000000000000000000000000000` if the above conditions are satisfied by a PoW block.
+    - `null` if client software cannot determine the ancestor of the invalid
+      payload satisfying the above conditions.
   * Client software **MUST NOT** surface an `INVALID` payload over any API endpoint and p2p interface.
 
 4. Client software **MAY** provide additional details on the validation error if a payload is deemed `INVALID` by assigning the corresponding message to the `validationError` field.