add description

Author: arobsn

eip-0031.md

@@ -119,30 +119,34 @@ Compilation of babel fee box smartcontracts for different tokens of interest wil
 
 The position of the recreated Babel Box in transaction's outputs must be set as a context extension variable in the spending Babel Box.
 
-1. Context variable `0`
+1. Context variable `0`:
     * Type: `SInt`
     * Value: position of the recreated Babel Box in transaction's outputs
 
 ### Parameters
 Parameters (creator’s public key and price) are specified via registers, meaning the resulting babel fee boxes from different creators will always belong to the same P2S address, which will improve their searchability.
 
-1. Register R4
+1. Register `R4`:
     * Type: `SigmaProp`
     * Value: creator's public key
-2. Register R5
+2. Register `R5`:
     * Type: `SLong`
     * Value: how much nanoErgs is the creator willing to pay for one babel token
+3. Register `R6`:
+    * Type: `SColl[Byte]`
+    * Value: id of the Babel Box being spent by this
+    * Only required for recreated boxes
 
 Babel fee box creator is able to spent the babel box in any circumstances.
 
-Other users on the other hand can spend this box as input to their transaction only when they also recreate it as output of their transaction with the very same registers (R4, R5) values together with insertion of a required amount of babel tokens (the amount of inserted babel tokens multiplied by the price specified in the R5 register has to be equal to or bigger than the amount of nanoErgs spent from the babel fee box).
+Other users on the other hand can spend this box as input to their transaction only when they also recreate it as output of their transaction with the very same `R4` and `R5` registers values together with `R6` as described above and insertion of a required amount of babel tokens (the amount of inserted babel tokens multiplied by the price specified in the R5 register has to be equal to or bigger than the amount of nanoErgs spent from the babel fee box).
 
 Wallets implementation
 --------------------------------------------
 
 Wallet developers will need to decide whether they want to support EIP-0031 or not. If they do decide to support this standard, they should also decide on which tokens they want to support (this could be done based on user requirements – e.g. implementing big stablecoins or “meme” coins, etc.), as this could be more convenient than supporting all tokens.
 
-As P2S addresses belonging to specific token of interest stay the same, these addresses could be easily “hardcoded” when supporting only a few tokens. If the developers decide to support any token, the previously mentioned smartcontract for each token which user holds should be compiled or "mounted" as described on ["Contract Template"](#contract-template) subsection and the availability of Babel Fee boxes (UTXOs) for the specific tokens of interest in the blockchain should be subsequently checked.
+As P2S addresses belonging to specific token of interest stay the same, these addresses could be easily “hardcoded” when supporting only a few tokens. If the developers decide to support any token, the previously mentioned smartcontract for each token which user holds should be compiled or "mounted" as described on ["Contract template"](#contract-template) subsection and the availability of Babel Fee boxes (UTXOs) for the specific tokens of interest in the blockchain should be subsequently checked.
 
 The proposed babel fee smartcontract is quite general and does not impose much restriction for the transaction. It is therefore possible to transact some tokens while paying babel fees with another tokens, etc.