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.
+new format.
\ No newline at end of file
+

[nanocryk]

1. Why store the signature in a checksumed value ? This is never used by users.
2. Why remove the private key ?

You should post a comment on the RFC merge request and not create your own, it'll be easier to track and manage.

[mmpio]

Sorry, I don't remember having made a merge request for those changes about private key, or did I accidentally through the command line ? I don't understand what happened. I was preparing this for commenting and asking questions because I was not sure to understand.

1.Why store the signature in a checksumed value ? This is never used by users.

That is where I think I may have not understand the purpose of these datatypes.

2.Why remove the private key ?

If the protocol manipulates private keys, they are not private anymore.

But again, I intented to ask the question before pushing a merge request.If i'm wrong can you clarify what is the context with an example ?

[nanocryk]

This data type is made to provide checksumed, currency-specific data containers where you can choose the cryptosystem you use. It would be used in clients to send currency to other addresses (to public keys or to script hashes directly) or to directly connect with the private key (with a checksum and "currency lock" for user-friendliness).

It's also used as a key format in script to test the cryptosystem and allow soft forks (unknown cryptosystem is "anyone can spend", see The script system).

For future reviews, you should go to the RFC5 merge request, go to the file and comment the line.