fix(specs/withdrawals): Sherlock #217

https://github.com/sherlock-audit/2023-01-optimism-judging/blob/b7921698c1c537714c5f2021aa46ce0a1935ba39/1-specs-findings/1-processed/1-true/two-step-not-in-spec/217.md#L1

specs/withdrawals.md

@@ -18,12 +18,14 @@ an L2 account to an L1 account.
 more specific terms to differentiate:
 
 - A _withdrawal initiating transaction_ refers specifically to a transaction on L2 sent to the Withdrawals predeploy.
+- A _withdrawal proofing transaction_ refers specifically to an L1 transaction which proves the withdrawal is correct (that it has been included in a merkle tree whose root is available on L1).
 - A _withdrawal finalizing transaction_ refers specifically to an L1 transaction which finalizes and relays the
   withdrawal.
 
 Withdrawals are initiated on L2 via a call to the Message Passer predeploy contract, which records the important
-properties of the message in its storage. Withdrawals are finalized on L1 via a call to the `OptimismPortal`
-contract, which proves the inclusion of this withdrawal message.
+properties of the message in its storage.
+Withdrawals are proven on L1 via a call to the `OptimismPortal`, which proves the inclusion of this withdrawal message.
+Withdrawals are finalized on L1 via a call to the `OptimismPortal` contract, which verifies that the fault challenge period has passed since the withdrawal message has been proved.
 
 In this way, withdrawals are different from [deposits][g-deposits] which make use of a special transaction type in the
 [execution engine][g-execution-engine] client. Rather, withdrawals transaction must use smart contracts on L1 for
@@ -59,7 +61,7 @@ This is a very simple contract that stores the hash of the withdrawal data.
 
 ### On L1
 
-1. A [relayer][g-relayer] submits the required inputs to the `OptimismPortal` contract. The relayer 
+1. A [relayer][g-relayer] submits a withdrawal proving transaction required inputs to the `OptimismPortal` contract. The relayer 
    is not necessarily the same entity which initiated the withdrawal on L2.
    These inputs include the withdrawal transaction data, inclusion proofs, and a block number. The block number
    must be one for which an L2 output root exists, which commits to the withdrawal as registered on L2.
@@ -69,7 +71,7 @@ This is a very simple contract that stores the hash of the withdrawal data.
    Note that the withdrawal can be proven more than once if the corresponding output root changes.
 1. After the withdrawal is proven, it enters a 7 day challenge period, allowing time for other network participants
    to challenge the integrity of the corresponding output root.
-1. Once the challenge period has passed, a relayer submits the withdrawal transaction once again to the
+1. Once the challenge period has passed, a relayer submits a withdrawal finalizing transaction once again to the
    `OptimismPortal` contract. Again, the relayer is not necessarily the same entity which initiated the withdrawal on L2.
 1. The `OptimismPortal` contract receives the withdrawal transaction data and verifies that the withdrawal has
    both been proven and passed the challenge period.