Closed christroutner closed 4 years ago
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.
After conversing with the team on this, perhaps a preferred workflow for this function would be:
false
to indicate it is not an SLP UTXO.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.isValid
property is marked false if SLPDB returns null
or false
.
b. An isValid
property is marked true if SLPDB returns true
.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.
PR #86 implements the following features:
false
is returned, the UTXO is safe to spend by an SLP-aware wallet.isValid
property along with the other SLP information.
isValid
will have a property of null
.isValid
will have a property of either true
or false
to indicate its SLP validity.This issue satisfied by PR #86
Capturing the results of a team conversation around
Util.tokenUtxoDetails()
.The current behavior
tokenUtxoDetails()
callsvalidateTxid()
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 asfalse
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.