PIP-0029: added clarification about including SEAL in account serialization

PIP/PIP-0029.md

@@ -111,7 +111,7 @@ A.Seal = HASH( SerializeAccount( A ) ++ OPID(O) ++ SafeBox.Root )
              HASH( X ) = RIPEMD160( SHA2_256 ( X ) )
              OPID(X) = RIPEMD160( SerializeOperation ( O ) )
              SafeBox.Root = the current committed SafeBoxHash resulting from the block tip , NOT the mempool SafeBoxHash
-             SerializeAccount ( X ) = account X serialized as an LE byte array as per network protocol
+             SerializeAccount ( X ) = account X serialized as an LE byte array as per network protocol (including the newly added seal field)
              SerializeOperation ( X ) = operatin X seraialized as an LE byte array as per ntwork protocol 
 ```
 
@@ -178,7 +178,7 @@ An account history is composed of a chronological order of account events. An ac
 
    function SerializeAccount(Account : TAccount) : TBytes;
    begin 
-     // as per network protocol
+     // as per network protocol INCLUDING the seal
    end
 ```
 
@@ -186,6 +186,7 @@ An account history is composed of a chronological order of account events. An ac
 * The above implementation does not validate the "final event" in the history, since by definition it is impossible as it requires knowledge of the "next event". 
 * If an auditor needs to validate a subset of an account history between events N..M, the account owner is required to provide the events N..(M+1). 
 * If an auditor is validating the full history, or a partial history up and until the live account state, the final element of the history should simply be the live account state copied from the SafeBox with all other fields set to nil or 0 (since they are not used or needed).
+* The account serialization includes the 20 byte seal
 
 ### Embedded-Chain Specification