Change Details

**Note: this diff was created by copying Tobias' draft at D16993 and updating the Cashtab test, + updating the cash-agora README** Currently, the token parameter approximation is really imprecise for "normal" amounts for USD amounts. For example, if someone offers 50 BUX tokens for $1 each (at $0.00003425/XEC), the actual price (for the maximum accepted amount) currently is $1.06/BUX, which is really imprecise, and precludes for any actual market discovery. A quick fix is really simple: We just bump `minTokenScaleFactor` from 1000 to 10000, which trades off token amount precision in favor of price precision. After this change, for the the same 50 BUX at $1 (for the maximum accepted amount), the actual price is $1.000017, which is much more precise (and the minimum is $1.0001). `minTokenScaleFactor` parameter has been mostly chosen at random anyway (1000 being a "nice" number), but now with a real application, we can start to tune approximation to be more user friendly. The tradeoff is that users won't be able to offer exactly 50 BUX, but instead 49.9968 BUX. and in 0.0256 BUX increments, but it's a reasonable assumption that users care more about price granularity than acceptable amount granularity. The long term solution is to bump Script integers to 64-bits, which would make approximation so precise that we don't really have to worry about it.

Currently, the token parameter approximation is really imprecise for "normal" amounts for USD amounts. For example, if someone offers 50 BUX tokens for $1 each (at $0.00003425/XEC), the actual price (for the maximum accepted amount) currently is $1.06/BUX, which is really imprecise, and precludes for any actual market discovery. A quick fix is really simple: We just bump `minTokenScaleFactor` from 1000 to 10000, which trades off token amount precision in favor of price precision. After this change, for the the same 50 BUX at $1 (for the maximum accepted amount), the actual price is $1.000017, which is much more precise (and the minimum is $1.0001). `minTokenScaleFactor` parameter has been mostly chosen at random anyway (1000 being a "nice" number), but now with a real application, we can start to tune approximation to be more user friendly. The tradeoff is that users won't be able to offer exactly 50 BUX, but instead 49.9968 BUX. and in 0.0256 BUX increments, but it's a reasonable assumption that users care more about price granularity than acceptable amount granularity. The long term solution is to bump Script integers to 64-bits, which would make approximation so precise that we don't really have to worry about it. (Note: this diff was created by copying Tobias' draft at D16993 and updating the Cashtab test, + updating the cash-agora README)

**Note: this diff was created by copying Tobias' draft at D16993 and updating the Cashtab test, + updating the cash-agora README** Currently, the token parameter approximation is really imprecise for "normal" amounts for USD amounts. For example, if someone offers 50 BUX tokens for $1 each (at $0.00003425/XEC), the actual price (for the maximum accepted amount) currently is $1.06/BUX, which is really imprecise, and precludes for any actual market discovery. A quick fix is really simple: We just bump `minTokenScaleFactor` from 1000 to 10000, which trades off token amount precision in favor of price precision. After this change, for the the same 50 BUX at $1 (for the maximum accepted amount), the actual price is $1.000017, which is much more precise (and the minimum is $1.0001). `minTokenScaleFactor` parameter has been mostly chosen at random anyway (1000 being a "nice" number), but now with a real application, we can start to tune approximation to be more user friendly. The tradeoff is that users won't be able to offer exactly 50 BUX, but instead 49.9968 BUX. and in 0.0256 BUX increments, but it's a reasonable assumption that users care more about price granularity than acceptable amount granularity. The long term solution is to bump Script integers to 64-bits, which would make approximation so precise that we don't really have to worry about it. (Note: this diff was created by copying Tobias' draft at D16993 and updating the Cashtab test, + updating the cash-agora README)