minimum redemption amount required to conversionRate UT Wei

[benjaminbollen]

for minimal precision of unstaking 1 ST Wei, we require minimum redemption amount to be required to be conversionRate UT Wei

fixes #39

[jasonklein]

LGTM for value chain.

Should something also be changed on the utility chain side? If not logic, then presumably at least a comment. When an account attempts to redeem a too-small-to-unstake-amount on the utility chain, all else being OK, that amount will be transferred from the account to the protocol, despite the account not being able to ultimately unstake for that amount on the value chain.

There is also the issue of rounding (i.e., 11/10 == 1, not 1.1) that we previously discussed. I accept that it's a crazy small amount of value, but it is not clear to me that users will be OK with value being lost without having been given any warning (especially if microtransactions start to add up). At this point, a comment should satisfy users. But I will leave the decision of whether and how to address the issue to you.

Perhaps ultimately the best solution is a comment rather than any change to the code, particularly given that OpenSTUtility does not retain conversion rate information post-proposal. Without additional coding changes, there's no way for OpenSTUtility to logically prevent accounts from essentially making donations to the protocol because they attempt to redeem un-unstakeable amounts.

[jasonklein]

@benjaminbollen, I struck out my discussion above w/r/t rounding because I just came to where you came to the same conclusion elsewhere.

[benjaminbollen]

Yes, @jasonklein current logic does not hold the conversionRate on the utilitychain side; this is a bit of an unfortunate UX; but we are still talking about negligible amounts; so negligible that it is hard to phantom how small; I would rather put in a more reasonable minimum redemption amount related to the actual cost to unstake; so we can open an issue for that:

microtransactions in BT is not the same as unstaking micro-amounts; even unstaking O(1) BT will not be cost effective.

[jasonklein]

@benjaminbollen, to confirm: (1) the solution is to place a requirement on the value chain that is not mirrored on the utility chain and (2) that solution is preferred over a comment about rounding/floating point math?

[benjaminbollen]

Correct; also very explicitly lets discuss this as a new issue and move this forward; merge and move