Depends on D15100
- Fix typo in toLocaleString() implementation
- Use tokenUtxo.slpToken.amount which, in the chronik utxo object, is already undecimalized (so save the op)
Details
Details
- Reviewers
Fabien - Group Reviewers
Restricted Project - Commits
- rABC71f4a9f3c96c: [Cashtab] Update getSlpSendTargetOutputs to match optimizations of…
npm test
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| cashtab/src/slpv1/index.js | ||
|---|---|---|
| 67 ↗ | (On Diff #43949) | not caught previously as unit tests are working with a token that does not have any decimals. this case is now tested for getSlpBurnTargetOutput only impact is structure of error msg, I don't think it's worth adding new utxo mocks to also test it here |
Comment Actions
AFAICT it's not only the error message that is changed, but also the behavior.
Say you have a token T with 1 decimal and 2 utxos worth 10.6T each. If you want to send 21T it would fail before that change and succeed after the change.
This change of behavior deserves a test.
Comment Actions
tokenUtxo.tokenQty !== tokenUtxo.slpToken.amount ... er well, it does, but only when decimals = 0.
new BN(tokenUtxo.tokenQty).times(10 ** decimals) === new BN(tokenUtxo.slpToken.amount) --> always true, assuming no issues with chronik indexing and delivery
chronik stores the "what's the actual amount when we take into account decimals" value at tokenUtxo.tokenQty as a string.
The SLP-spec-friendly way of storing it (integer) is kept at tokenUtxo.slpToken.amount as a string.
So, we should just use the string that is already an integer, instead of re-converting this new string.
| cashtab/src/slpv1/fixtures/mocks.js | ||
|---|---|---|
| 113 ↗ | (On Diff #43978) | note that slpToken.amount has one more zero than tokenQty, which is how chronik returns data for an slpv1 token with decimals = 1 |
| cashtab/src/slpv1/fixtures/vectors.js | ||
| 123 ↗ | (On Diff #43978) | 04, pushdata |
Comment Actions
You misunderstood what I wrote, and that's my fault. I wrote the token is named T, so 10.6T is not Tera but 10.6 of the token quantity.
Let's call the token FOO, you have twice 10.6 FOO and want to send 21 FOO => you got the decimal case that is worth checking in the test.