feat: report channel details in correct asset scale #50
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: report channel details in correct asset scale
Example: current network defaults use asset scale 9 (whereas drops are asset scale 6), so if I run
ilp-spsp send --amount 1000000 --receiver '$xxx'
my resulting balance will be increased by 1,000 (not 1,000,000). At no point in the default workflow is this information conveyed to the user.In this PR I propose we reflect the user's configured asset scale in the
moneyd xrp:info
and similar reports to avoid such confusion. For example, an asset scale of 9 would result in the following display:One thing I would like to be sure of in review is that this does not behave improperly when running multiple moneyd instances with different config files (and different asset scales) on the same machine. Any other bits of feedback welcome too.
Also, the moneyd README says the command
moneyd xrp:topup --amount 1000
will topup 1000 drops regardless of asset scale. This is a further source of confusion. However,xrp:topup
appears to have no effect currently - so asset scale issues are probably not the most pressing. That being said, it's likely worth investigating which other areas of the code might be exhibiting the same confusing behaviour addressed in this PR.If some are identified, I would be happy to add more fixes before merging.