Util.tokenUtxoDetails() should check all UTXOs

[christroutner]

Capturing the results of a team conversation around Util.tokenUtxoDetails().

The current behavior

tokenUtxoDetails() calls validateTxid() for each UTXO it receives, to have SLPDB validate each UTXO. For those UTXOs that come back as valid, the raw transaction data is retrieved from the full node and the OP_RETURN data decoded.

The desired behavior

tokenUtxoDetails() should retrieve the raw transaction data directly from the full node and check for the presence of an OP_RETURN. If there is no OP_RETURN, it can mark the UTXO as false to indicate it is not an SLP UTXO. For those with an OP_RETURN, it should attempt to be decoded. No calls need to be made to SLPDB.

Reasoning

The reason for this change is a realization that SLPDB may not know about a TX, and thus may erroneously return a false negative that would cause a wallet to burn a token. This new method increases demands on full nodes and increases computation, but removes the risk of burning tokens.

[christroutner]

Update: This change would remove the validation capability. There would need to be a second call or some other method to ensure an SLP UTXO is valid.

[christroutner]

After conversing with the team on this, perhaps a preferred workflow for this function would be:

1. Raw transaction data for every UTXO is retrieved from the full node.
2. For those TXs without an OP_RETURN, the entry is marked false to indicate it is not an SLP UTXO.
3. For those TXs with an OP_RETURN, the data is parsed for SLP data.
   a. If the data can not be parsed, the UTXO is marked false to indicate it is not an SLP UTXO.
   b. If the data can be parsed, the TXID is sent to SLPDB to ask if the UTXO is valid.
4. (after 3b only) SLPDB is called to validate the UTXO.
   a. An isValid property is marked false if SLPDB returns null or false.
   b. An isValid property is marked true if SLPDB returns true.

[SpicyPete]

Looks like a good solution, if the validation here would be too heavy, the apps could also rely on a second call such as to validatetxid. Assuming this endpoint always has accurate information.
https://developer.bitcoin.com/slp/docs/js/util#validatetxid

Also regarding isValid, I think the property needs to be null or false if it's false in SLPDB, true if marked as true, and some indeterminate value if it's an SLP UTXO but unknown to SLPDB.

[christroutner]

PR #86 implements the following features:

• if false is returned, the UTXO is safe to spend by an SLP-aware wallet.
• If the UTXO is colored with SLP information, then it includes an isValid property along with the other SLP information.
  • If SLPDB is not aware of the SLP UTXO, isValid will have a property of null.
  • If SLPDB has processed the SLP UTXO, isValid will have a property of either true or false to indicate its SLP validity.

[christroutner]

This issue satisfied by PR #86