From 937c720fb1b08e66acf0d2cc69bf740aa3497f37 Mon Sep 17 00:00:00 2001
From: Nanocryk <nanocryk@gmail.com>
Date: Sun, 26 Nov 2017 10:14:06 +0100
Subject: [PATCH] Corrections
---
DIP0001.md | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/DIP0001.md b/DIP0001.md
index 64ba560..ac1449e 100644
--- a/DIP0001.md
+++ b/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>
--
GitLab