added link and explanation where the constant is defined at top of file

The spec does not go into much detail as to why 19 was selected, but I assume it's because this is the most that will fit in a 223-byte OP_RETURN. An SLP1 send tx with 19 outputs has 217 bytes in the OP_RETURN. 20 outputs would be 236 bytes, over the 223 allowed.

Defined in spec as no way to know if OP_RETURN field could be expanded later on. Were this to happen, other parts of SLP may be worth redesigning. Probably was a good idea to keep the spec constant independent of potential protocol changes, at least in this version.

Lots of confusing things about these NFTs from the dev perspective.

• Per spec, when you mint an SLP1 token, you can only mint to one output (the output at index 1)
• So, if you want to mint more than 1, all the qty can only be in 1 utxo
• To "genesis" a child NFT though, we need a utxo of qty exactly 1

So we will have to fan out.

Now, say you have qty 100 of NFT parent. You want to make as many qty 1 utxos as possible.

Your only available input is this qty 100 utxo.

So, 1 input, 100.

As for outputs, you can only have 19 of those. So, at most, you can make 19 qty-1 outputs. However, if you make 19 qty-1 outputs from an input utxo of 100....well, you just burned 81 of the parent token (inputs = 100 and outputs = 19x1 = 19).

So -- we need a change output to keep from burning any of the original qty.

Input 100 -- 18 outputs of 1 -- and a change output of 82. Now inputs === outputs and we can use the new utxo of 82 to create more fan txs in the future.

So, we can only create exactly 19 qty-1 outputs if our input amount happens to be exactly 19.

Function has to handle 3 cases

• Input utxo(s) of exactly 19 --> create 19 qty-1 outputs and no change
• Input utxo(s) of more than 19 --> create 18 qty-1 outputs and change
• Input utxo(s) of less than 19 (say, "n") --> create "n" qty-1 outputs and no change

These 3 cases are the test vectors for this function.