bips#10: small wording changes and typo fixes

bsip-0010.md

@@ -17,7 +17,7 @@ This proposal is also important for another reason: it paves the way for adding
 # Abstract
 Any percentage-based transfer fee scheme needs some kind of basis for deriving the actual BTS value of the amount being transferred. The core idea of this approach is to derive this value from the *Core Exchange Rate* (CER) which is defined by the asset's issuer.  A complementary modification in the referral system is also needed in order to prevent abuse on the part of referrers.
 
-If the minimum transfer fee is kept at a reasonable level (i.e. around 6 BTS), the only actors actually affected by this proposal are referral businesses, as their revenue stream will be negatively affected for smaller transfers but in exchange positively affected for larger ones. The effect for issuers will only be positive or none at all, as for them this an opt-in feature. As for shareholders in general, the change will be positive because BitShares will become more competitive in terms of transfer fees when compared to other systems. 
+If the minimum transfer fee is kept at a reasonable level (i.e. around 6 BTS), the only actors actually affected by this proposal are referral businesses, as their revenue stream will be negatively affected for smaller transfers but in exchange positively affected for larger ones. The effect for issuers will only be positive or none at all, as for them this is an opt-in feature. As for shareholders in general, the change will be positive because BitShares will become more competitive in terms of transfer fees when compared to other systems. 
 
 If we keep the minimum fee at around 6 BTS, the financial effect for the blockchain itself will be neutral, as all profits (or losses) will be absorbed by the referrers. However, an overall increase in the network's revenue is expected, as it is safe to assume that, once small transfers get significantly cheaper, there will be more of them and each of them will contribute to the network's revenue.
 
@@ -25,11 +25,12 @@ If we keep the minimum fee at around 6 BTS, the financial effect for the blockch
 Having a flat transfer fee of 30 BTS for non-LTM users, currently BitShares cannot be regarded as a competitive payment solution for transfers below the equivalent of $5. The current fee in this case is above 2%, which is way more than any legacy system wants to charge its customers.
 
 There are two important objectives this proposal aims to achieve:
-* to allow users to pay lower transfer fees for smaller transfers (while charging them more on bigger transfers)
 
+* to allow users to pay lower transfer fees for smaller transfers (while charging them more on bigger transfers)
 * to allow referrers to earn extra income associated with bigger transfers (while taking away from them the current income associated with smaller transfers).
 
 Apart from that, we would like to make detailed documentation a crucial part of this proposal, thus offering an important benefit for the whole ecosystem: a step-by-step description how to implement new features without relying on CNX so that other coders & entrepreneurs can follow our example. The documentation will entail:
+
 * programming context: a brief overview of Graphene's architecture
 * what changes have been made in the code and their rationale
 * how unit testing and testnet verification has been approached
@@ -38,7 +39,7 @@ Apart from that, we would like to make detailed documentation a crucial part of
 This documentation will hopefully become the foundation of a larger tutorial for Graphene developers. The work on this material has already been started and a brief preview can be accessed [here](https://neura-sx.gitbooks.io/graphene-book/content/).
 
 # Rationale
-The simplest way to solve the "high transfer fee" problem would be to lower transfer fees for all assets. However this would effectively negatively affect the referral program. On the other hand, a simple percentage-based transfer fee system is not doable, as for most assets we do not have a viable way to determine their exact value at any given time. This is mainly due to the fact that most markets are very illiquid but also due to the difficulty of establishing an asset's price in a manner which is deterministic enough to reliably prevent unintended hard-forks.
+The simplest way to solve the "high transfer fee" problem would be to lower transfer fees for all assets. However this would effectively negatively affect the referral program. On the other hand, a simple percentage-based transfer fee system is not doable, as for most assets we do not have a viable way to determine their exact value at any given time. This is mainly due to the fact that many markets are very illiquid by nature (such as SIVER:GOLD) but also due to the difficulty of establishing an asset's price in a manner which is deterministic enough to reliably prevent unintended hard-forks.
 
 Also, a percentage-based transfer fee system, if introduced without any modifications to the referral program, would open up the possibility for referrers to game the system by transferring small amounts back and forth between their own accounts just to collect the referral award at the expense of issuers. Therefore, for assets enjoying a percentage-based transfer fee system, referrers' revenue structure has to be percentage-based as well.
 
@@ -46,14 +47,14 @@ Also, a percentage-based transfer fee system, if introduced without any modifica
 #### The assumptions
 The following description uses a fictional asset called BAX but this solution can be applied to all assets (i.e. both public and private SmartCoins, UIAs and FBAs) and all non-stealth transfers. Also, what is described below refers to pay-as-you-go users. For LTM users exactly the same rules apply, except for the fact that in this case the referrer's income is redirected to the user's cash-back fund.
 
-> Please note that values used in the description below are just an initial proposal, the actual values will be determined be the committee.
+> Please note that values used in the description below are just an initial proposal, the actual values will be determined be the committee by means of global blockchain parameters.
 
 #### The concept
-The transfer fee can be paid either in BTS or BAX.
+For a transfer of BAX, the transfer fee can be paid either in BTS or BAX.
 
 1. If the user chooses to pay the fee in BTS:
   * The transfer fee is equal to 1% of the BTS value of the BAX amount being transferred, adjusted by a floor (i.e. minimum fee) and a cap (i.e. maximum fee): 6 BTS and 300 BTS respectively. So effectively the transfer fee is 1% but it is never less than 6 BTS and never more than 300 BTS.
-  * To establish the BTS value of the transfer, CER is used.
+  * To establish the BTS value of the transfer, CER of BAX is used.
   * The fee paid by the user is split as follows: 6 BTS goes to the network, any excess above 6 BTS goes to the referrer.
   * The issuer does not earn anything.
 2. If the user chooses to pay the fee in BAX:
@@ -61,7 +62,7 @@ Let *F* be the transfer fee (expressed in BTS) which was calculated as described
   * To establish the BAX equivalent of *F*, CER is used.
   * The issuer receives the entire fee paid by the user in BAX.
   * The following amounts are deducted from the asset fee pool: 6 BTS goes to the network, and (*F* - 6) BTS goes to the referrer.
-  * The issuer makes a profit or loss, depending on CER being above or below the actual BTS/BAX exchange rate.
+  * The issuer makes a profit or loss, depending on CER being above or below the actual BTS/BAX exchange rate in the same way as it is currently implemented in the flat fee model.
 
 #### The main issue
 What happens when the issuer attempts to artificially lower transfer fees on his asset by pretending his asset is not worth much and deliberately keeping CER below the actual BTS/BAX exchange rate?
@@ -70,10 +71,11 @@ What happens when the issuer attempts to artificially lower transfer fees on his
 - for the referrer: no matter if the user pays the fee in BAX or BTS, he is deprived of a large part of the referral reward, as due to distorted CER, transfers are interpreted by the system as involving smaller value than they actually are.
 
 #### How is this issue solved?
-By keeping CER artificially low, the issuer will effectively discourage users from using his own asset because transfer fees will only be low when paid in BTS, so the process of transferring the asset will be dependent on users having BTS in their wallets to cover the fees. Furthermore, if the issuer distorts CER too much, he'll not be able to benefit from it himself as users will start avoiding paying the fees in BAX. Also, it will be bad PR for the issuer to value his own asset below the market rate. At least in case of SmartCoins (both public & private) issuers are not likely to be wiling to sabotage their own assets in this way.
+By keeping CER artificially low, the issuer will effectively discourage users from using his own asset because transfer fees will only be low when paid in BTS, so the process of transferring the asset will be dependent on users having BTS in their wallets to cover the fees. Furthermore, if the issuer distorts CER too much, he'll not be able to benefit from it himself as users will start avoiding paying the fees in BAX. Also, it will be bad PR for the issuer to value his own asset below the market rate. At least in case of SmartCoins (both public & private) issuers are not likely to be willing to sabotage their own assets in this way.
 
 #### Additional abuse prevention mechanism
 However, if it turns out that a large number of issuers try to game the system, in the future we can introduce the following mechanism aimed at preventing abuse on the part of issuers:
+
 * To enable percentage-based transfer fees, the issuer will be obliged to keep an open ask order on the BTS:BAX market and thus allow anybody to buy BAX at e.g. 120% of CER. As a result, if CER is out of sync with the market rate by more than 20%, the issuer will incur a significant loss.
 * If the issuer is not willing to comply with the above requirement, the default flat transfer fee structure will be applied.
 
@@ -81,8 +83,10 @@ However, if it turns out that a large number of issuers try to game the system,
 
 #### This is an opt-in feature
 As the issuer is the only entity that actually controls CER, the percentage-based transfer fee is meant to be an opt-in feature decided by the issuer. It is safe to assume that most issuers will find it beneficial for their assets because:
+
 * assets which are worth something will benefit from having a reasonable pricing structure for transfers
 * assets which are worth nothing or almost nothing (i.e. most UIAs) will be able to be transferred almost for free (for 6 BTS instead of the current 30 BTS).
+
 However, if an issuer for some reasons does not find the above features beneficial, he will be able to keep the existing flat fee structure.
 
 #### The intended workflow
@@ -105,6 +109,7 @@ As for the BitShares network itself, the overall impact of this proposal will be
 # Areas covered
 This proposal covers the entire implementation of percentage-based fees.  
 In particular, the following aspects will be covered:
+
 * coding
 * code review by CNX
 * unit testing and testnet testing
@@ -114,18 +119,15 @@ In particular, the following aspects will be covered:
 
 # Known issues and limitations
 There are the following issues and limitations that cannot be overcome:
-* The percentage-based fee scheme cannot be applied to stealth transfers (due to the very nature of stealth transactions, it's impossible to determine their BTS value).
 
+* The percentage-based fee scheme cannot be applied to stealth transfers (due to the very nature of stealth transactions, it's impossible to determine the amount transfered).
 * This proposal covers all SmartCoins (both public and private), UIAs and possibly also FBAs (once they get implemented). ~~However, due to technical reasons, the percentage-based fee scheme cannot be applied to the core currency i.e. BTS.~~  
-EDIT: Together with CNX, we are actively looking at ways to find a solution to this problem - one of the options considered is changing the ownership of BTS from `null-account` to `committee-account`.
-
+  EDIT: Together with CNX, we are actively looking at ways to find a solution to this problem - one of the options considered is changing the ownership of BTS from `null-account` to `committee-account`.
 * There might be a negative UX in a very rare situation: when CER is being updated by the issuer between the moment the user hits `Transfer` and the moment s/he hits `Confirm`. In this situation the user might receive an error message about not supplying sufficient funds to cover the transfer fee and will have to redo the transfer.  
-EDIT: Thanks to [this suggestion](https://bitsharestalk.org/index.php/topic,21080.msg275323.html#msg275323) by `roadscape`, there might be a viable workaround for this issue at the GUI level.
-
+  EDIT: Thanks to [this suggestion](https://bitsharestalk.org/index.php/topic,21080.msg275323.html#msg275323) by `roadscape`, there might be a viable workaround for this issue at the GUI level.
 * ~~In case of committee-controlled SmartCoins, occasionally there might be a small discrepancy between the current value of CER and the value of CER enclosed in the committee proposal to switch a given SmartCoin to the percentage-based mode.~~  
-EDIT: We will most probably be able to offer a patch to the code-base, which will make it possible to update an asset without changing CER, and thus fix this issue.
-
-*  If the committee decides to apply percentage-based fees to SmartCoins, our partners (e.g. exchanges, gateways etc) need to notified in advance, so that they have time to adjust their applications, and make sure those applications and their pricing policy are compatible with percentage-based fees.
+  EDIT: We will most probably be able to offer a patch to the code-base, which will make it possible to update an asset without changing CER, and thus fix this issue.
+*  If the committee decides to apply percentage-based fees to SmartCoins, our partners (e.g. exchanges, gateways etc) need to be notified in advance, so that they have time to adjust their applications, and make sure those applications and their pricing policy are compatible with percentage-based fees.
 
 # Copyright
 This document is placed in the public domain.