A constant value that recognizes that the data should be interpreted according to this format.
A possible future format must use a different magic value.
### Version
Future versions of the present format must increment this byte.
### Message type
| Code | Significance |
|:----:|:---------------:|
| 0x00 | For a human |
| 0x01 | For a machine |
### Nonce
An sequence of 16 random bytes to use as scrypt salt
### Real message length
Indicates the real size of the message in bytes. That is, the number of bytes that should be interpreted as an UTF8 string. There may be extra bytes, the extra bytes should be ignored (see section "Random extra bytes").
### Random extra bytes
The presence of extra bytes only serves to hide the real length of the message from outside observers.
There may well be no extra bytes, just as there may be many.
It is recommended to randomly generate a random number of extra bytes to obscure the real length of the message.
## Encoding in transaction document
Encrypted message in encoded in base 64 (without padding) in transaction comment directly (DUBP protocol already accept all base 64 characters).
## Maximum message length
The DUBP protocol allows up to 255 characters in the comment field, so it is possible to encode up to 191 bytes in base64 (without padding).
There are at least 21 bytes of metadata, so the maximum size of a message is **170 bytes**.
## Quickly recognize if a comment fits this format
You can quickly recognize if a comment fits this format with the following regex: `J7YB[0-9a-zA-Z+/]{24,}`
## Encrypt transaction comment (Issuer side)
Let `m` the user message bytes encoded in UTF8.
Let `t` the message type.
1. Generate 16 random bytes and stores them in a byte array `nonce`.
1. Compute `l = m.lenght`
1. Generate a random integer `x` between `0` and `170 - l`
1. Generate `x` random bytes and add them at end of `m`.
1. compute `L = l + x + 1`
1. compute `Si'` and `Pr'`.
1. Create a bytes array `dataToEncrypt` of length `L`