Update EIP-6404: Remove placeholder TBD sections

Merged by EIP-Bot.
ethereum · Jan 9, 2024 · 9d0bee7 · 9d0bee7 · Perry2186 · Jan 11, 2024
1 parent dfee781
commit 9d0bee7
Show file tree

Hide file tree

Showing 4 changed files with 0 additions and 32 deletions.
diff --git a/EIPS/eip-6404.md b/EIPS/eip-6404.md
@@ -79,14 +79,6 @@ Applications that rely on the replaced MPT `transactions_root` in the block head
 
 While there is no on-chain commitment of the `tx_hash`, it is widely used in JSON-RPC and the [Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/6b259a7003b4bfb18365ba690f4b00ba8a26393b/caps/eth.md) to uniquely identify transactions. The `tx_root` is a different identifier and will be required for use cases such as transaction inclusion proofs where an on-chain commitment is required.
 
-## Test Cases
-
-TBD
-
-## Reference Implementation
-
-TBD
-
 ## Security Considerations
 
 None

diff --git a/EIPS/eip-6465.md b/EIPS/eip-6465.md
@@ -113,14 +113,6 @@ Applications that rely on the replaced MPT `withdrawals_root` in the block heade
 
 Clients can differentiate between the legacy withdrawals and typed withdrawals by looking at the first byte. If it starts with a value in the range `[0, 0x7f]` then it is a new withdrawal type, if it starts with a value in the range `[0xc0, 0xfe]` then it is a legacy withdrawal type. `0xff` is not realistic for an RLP encoded withdrawal, so it is reserved for future use as an extension sentinel value.
 
-## Test Cases
-
-TBD
-
-## Reference Implementation
-
-TBD
-
 ## Security Considerations
 
 None

diff --git a/EIPS/eip-6466.md b/EIPS/eip-6466.md
@@ -78,14 +78,6 @@ This change enables the use of SSZ transactions as defined in [EIP-6493](./eip-6
 
 Applications that rely on the replaced MPT `receipts_root` in the block header require migration to the SSZ `receipts_root`.
 
-## Test Cases
-
-TBD
-
-## Reference Implementation
-
-TBD
-
 ## Security Considerations
 
 None

diff --git a/EIPS/eip-6493.md b/EIPS/eip-6493.md
@@ -523,14 +523,6 @@ Existing RLP transactions can be converted to SSZ transactions. Their original `
 
 Existing RLP receipts can be converted to SSZ receipts. The full sequence of accompanying transactions must be known to fill-in the new `contract_address` field. Note that because JSON-RPC exposes the `contract_address`, implementations are already required to know the transaction before queries for receipts can be served.
 
-## Test Cases
-
-TBD
-
-## Reference Implementation
-
-TBD
-
 ## Security Considerations
 
 SSZ signatures MUST NOT collide with existing RLP transaction and message hashes.