Corrections

DIP0001.md

@@ -63,7 +63,7 @@ As seen in exemples above, we have to manage different types of tree nodes :
 - **Local values of different types** : leaf nodes with values stored in the script (like pubkeys)
 - **Extern values** : leaf nodes with values provided as input to the script (like signatures)
 
-We'll also need a valid way to not provide an ununsed input, and to provide the hash of an AST.
+We'll also need a valid way to not provide an ununsed/undefined input, and another one to provide the hash of an AST.
 
 We can define opcodes to encode this information :
 
@@ -160,9 +160,10 @@ Input parameters are provided in a list of AST with indexes.
 In the exemple of 2 out of 3 signatures above, the input could be :
 
 ```
-0 : U64 <signature_a>
-1 : NOP
-2 : U64 <signature_b>
+3
+    U64 <signature_a>
+    NOP
+    U64 <signature_c>
 ```
 
 In the document, they will be expressed as `<size on 2 bytes> <ast1> <ast2> ...`.
@@ -203,7 +204,7 @@ pubkey   signature
 
 If the left signature verification returns true, the `OR` operator returns true. Otherwise it will propagate the **undefined state**.
 
-At the end the response is `UNDEFINED`. For a calculating node, this transaction is invalid. For a mirror node, it can consider it valid if it comes from a calculating node. Further verifications may be necessary.
+If at the end the returned value is `UNDEFINED`, the execution is concidered invalid and the transaction can't be spent.
 
 # Merklized trees
 
@@ -244,10 +245,11 @@ SMR 2
 Then when you want to use it, you provide as parameters :
 
 ```
-0 : U64 <signature_a>
-1 : NOP
-2 : U64 <signature_c>
-3 : GE 2
+4
+    U64 <signature_a>
+    NOP
+    U64 <signature_c>
+    GE 2
         SUM 3
             ED 2
                 U32 <public_key_a>