Replace currency "values" by currency "amounts"

rfc/0005 Duniter Protocol Rework.md

@@ -122,7 +122,7 @@ Since hashes are stored on 32 bytes, a *blockstamp* is stored on a 36 bytes valu
 
 > Note that is says "might be" because the hash is not known in advence.
 
-### Currency values
+### Currency amounts
 
 > To simplify explanations, we'll work with Ğ1 currency as an example. The currency symbol be
 > replaced by any other currency made with Duniter.
@@ -136,22 +136,22 @@ user-friendliness.
 - 1 MĞ1 = 1 000 000 Ğ1 = 1 000 000 000 units
 - 1 GĞ1 = 1 000 000 000 Ğ1 = 1 000 000 000 000 units
 
-Currency values are stored as :
+Currency amounts are stored as :
 
 | Size | Data |
 |:----:|:-----|
 | *1 byte* | Base
-| *7 bytes* | Signed value in units
+| *7 bytes* | Units as signed value
 
-> Value need to be signed to allow operations on them within scripts.
+> Units need to be signed to allow operations on them within scripts.
 
-The real value is calculated as :
+The real amount is calculated as :
 
 ```txt
-RealValue = Value * 10^Base
+RealAmount = Units * 10^Base
 ```
 
-Since the base will grow forever, it needs to cycle. We can compare values in an interval of
+Since the base will grow forever, it needs to cycle. We can compare amounts in an interval of
 `[-128;127]` around the main base.
 
 > TODO : better explain ranges
@@ -159,7 +159,7 @@ Since the base will grow forever, it needs to cycle. We can compare values in an
 This base incrementation will be very slow and a full cycle won't append until a long time. When the
 UD becomes greater than `2^16` units, we increment the base.
 
-We also need to update the displayed value, as it will be impractical to display them as very large
+We also need to update the displayed amounts, as it will be impractical to display them as very large
 numbers. A suggested solution is to talk about *Dunes* or *Ď1* as a *Dividend Ğ1*, since *Ď1* are
 not going to grow exponentialy.
 
@@ -264,15 +264,14 @@ This format (called an **address**) is structured as :
 | Data type | Payload size | Description
 |:---------:|:------------:|:------
 | 0 | 32 | account
-| 2 | 32/64 | [ed25519] public/private key
+| 1 | 32 | [ed25519] public key
+| 2 | 64 | [ed25519] signature
 | 3 | 32 | [ed25519] public key hash
 
 > More data types will be added in the future.
 
 [ed25519]: https://en.wikipedia.org/wiki/EdDSA
 
-The difference between public and private keys can be infered by the context and size.
-
 The checksum is the first 4 bytes of `SHA256(CurrencyCode ++ DataType ++ Payload)`
 
 > With this format it will be very unlikely someone send to an unwanted address.
@@ -398,11 +397,11 @@ A `Transaction` document contains the following :
 |
 | | **For each source** :
 | 32 | Source
-| 8 | Currency value taken from this account
+| 8 | Currency amount taken from this account
 | ... | *Unlock parameters (with alignement padding with `Nop` opcodes)*
 |
 | | **For each output** :
-| 8 | Currency value to send to this account
+| 8 | Currency amount to send to this account
 | 1 | Output type
 | 1 | Script system version
 | ... | *Lock script (with alignement padding with `Nop` opcodes)*
@@ -763,4 +762,5 @@ with the payload being the text v10 document. This document don't need any issue
 since these are already in the v10 document.
 
 When inserted into the state, signatures are no longer needed and documents can be converted in the
-new format.
\ No newline at end of file
+new format.
+