Change Details

Add supporting utxo selection and tx building for SLP_TOKEN_TYPE_NFT1_GROUP, aka NFTs. Note that NFTs on XEC have some intricacies with the spec that could be greatly simplified by using this kind of library. Namely, users must deal with minting "Collection" or "Group" tokens. Then they must "fan out" these tokens to create utxos with qty-1. Then exactly 1 of these utxos must be at the index-0 input of the tx that mints an NFT. I looked at making this simplification in the initial implementation, i.e. if a user tries to mint an NFT, the lib automatically fans out. However this is nontrivial. This logic is not necessary for Cashtab drop-in. Due to the associated complexity, it should be handled in its own diff, if it is added.

Add supporting utxo selection and tx building for SLP_TOKEN_TYPE_NFT1_GROUP, aka NFTs. Note that NFTs on XEC have some intricacies with the spec that could be greatly simplified by using this kind of library. Namely, users must deal with minting "Collection" or "Group" tokens. Then they must "fan out" these tokens to create utxos with qty-1. Then exactly 1 of these utxos must be at the index-0 input of the tx that mints an NFT. I looked at making this simplification in the initial implementation, i.e. if a user tries to mint an NFT, the lib automatically fans out. However this is nontrivial. This logic is not necessary for Cashtab drop-in. Due to the associated complexity, it should be handled in its own diff, if it is added. Properly, though, if NFTs on eCash are to become important and useful -- it would be much better to come up with a new ALP-based spec. Some advantages of an ALP NFT: - Eliminates requirement for "preparatory" tx for listing on agora - Could eliminate the requirement for "fan-out" txs; instead, with ALP, you could design the spec such that we BURN qty 1 of the parent token and GENESIS qty 1 of the NFT in the same tx, while providing token change. - Could include messages in NFT txs, which could be used programmatically for things like encoding changes in privileges, associations, or sale royalties So, in improving NFT support, it would be higher ROI to engineer this kind of spec than to obfuscate the complexities of the existing SLP NFT spec as much as possible. `ecash-wallet` could obfuscate the preparatory txs and the fan out txs. But it could never fix the problem of "we cannot include msgs or app data in NFT txs" ... and I think that could be particularly useful especially for non-image NFTs.

Add supporting utxo selection and tx building for SLP_TOKEN_TYPE_NFT1_GROUP, aka NFTs. Note that NFTs on XEC have some intricacies with the spec that could be greatly simplified by using this kind of library. Namely, users must deal with minting "Collection" or "Group" tokens. Then they must "fan out" these tokens to create utxos with qty-1. Then exactly 1 of these utxos must be at the index-0 input of the tx that mints an NFT. I looked at making this simplification in the initial implementation, i.e. if a user tries to mint an NFT, the lib automatically fans out. However this is nontrivial. This logic is not necessary for Cashtab drop-in. Due to the associated complexity, it should be handled in its own diff, if it is added. Properly, though, if NFTs on eCash are to become important and useful -- it would be much better to come up with a new ALP-based spec. Some advantages of an ALP NFT: - Eliminates requirement for "preparatory" tx for listing on agora - Could eliminate the requirement for "fan-out" txs; instead, with ALP, you could design the spec such that we BURN qty 1 of the parent token and GENESIS qty 1 of the NFT in the same tx, while providing token change. - Could include messages in NFT txs, which could be used programmatically for things like encoding changes in privileges, associations, or sale royalties So, in improving NFT support, it would be higher ROI to engineer this kind of spec than to obfuscate the complexities of the existing SLP NFT spec as much as possible. `ecash-wallet` could obfuscate the preparatory txs and the fan out txs. But it could never fix the problem of "we cannot include msgs or app data in NFT txs" ... and I think that could be particularly useful especially for non-image NFTs.