to be consistent with the other libraries initialized in the monorepo. this is what ecash-script published at.

This constant, together with SATOSHIS_PER_BYTE, could be used in other functions. define at the top of the file for now.

I get this this approach probably makes it more difficult for a new-ish dev to burn SLP utxos. Still, seems a bit wasteful, as the only wallet example we are familiar with -- Cashtab -- already stores these separately.

The right solution here would be to patch chronik-client utxos() output to return utxos separated by xec / slp

If that is impractical, imo best to leave parseChronikUtxos as a standalone exported function in this lib, to be used by devs as they see fit

So, this function should require xecUtxos as a param, not chronikUtxos

we don't want to be defining this at every i in the for loop, see comment above re: DUST

imo the complications around prefix and postfix discrepancies with the decrement operator are not worth the character savings

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Decrement

why not return the outputs here?

this won't exist if the user is passing chronik response of an address with no balance. in this case, the function should still return {xecUtxos: [], slpUtxos: []}

add unit test for chronik response of an address with on balance

instead of 818, find a tx in the wild and get the rawtx. Then rawTx.length / 2

Add and configure mocha-suppress-logs, which is installed for alias-server, ecash-herald, and ecash-script

requires a .mocharc.js file, contents like

'use strict';

module.exports = {
    require: 'mocha-suppress-logs',
    timeout: 15000,
};

update for outputValues array

this should be changeAmountInSats

ok, based on the current scope of the function, let's not return outputValues

instead, return

{inputUtxos, changeAmount, txFee}

this is the info that will be needed for the tx builder in the next step (well, not txFee, but that is still interesting to know and could be used for some applications)

Add a couple of additional tests for this using different input and output counts

In this case, your change amount is 0 -- even though remainder may be, say 500 sats. Note this also impacts the fee of the tx: we are returning the ideal tx fee, but the actual fee will be higher, since we aren't going to bother returning change < dust (so actual fee in this case would be ideal fee + 500 sats).

tricky to draw the line here in terms of what a dev using this tool expects as output vs what should just come straight out of this tool. If we return 0 as a change amount, the app dev still has to handle that when creating outputs, i.e. "if change amount is 0, do not create an output for change." If we return 500, as this code would do now, the app dev has to check "if change amount is less than dust, don't add change"

imo we want this to be a simple as possible. App dev shouldn't need to know "546". So, if there is no change, return 0 for change amount.