Several questions and feature requests on transaction building

[doitian]

I have several questions and feature requests related to the transaction building.

• In common-scripts/sudt, the method issueToken does not support setting the receiver address, so I cannot issue the token to a user directly.
• Assume that an account has a SUDT cell which capacity is not enough to create two SUDT cells, and this account also have a CKB cell with sufficient capacity. If I use transfer method in common-scripts/sudt, it will add the two cells as inputs, and create one SUDT output cell for the recipient, and another SUDT output cell for both the SUDT change and the CKB change. However, I expect two change cells, one for SUDT with just enough capacity, and another CKB change cell without type script for the remaining capacity.
• In the example above, I cannot call payFee or payFeeByFeeRate on the generated txSkeleton, because it has already included all the cells in the account, although there's enough capacity in the change cell to pay the fee.
• I tried to create a CKB transfer using the method transfer in common-scripts/secp256k1_blake160, it will burn the SUDT cells to provide enough capacity. What's the recommended way to create a simple CKB transfer transactions but filtering out input cells that have a type script?
• The transfer method in common-scripts/sudt accepts any address in fromInfos, but it will not use the address to find input cells with the corresponding lock script. Instead, the method will use the args as a public key hash, and use it to find cells locked by the builtin system lock scripts. It seems a unnecessary dependency on the system lock scripts.

[homura]

Thanks for your feedback

In common-scripts/sudt, the method issueToken does not support setting the receiver address, so I cannot issue the token to a user directly.

This feature seems a bit hard to define the parameters of issueToken, because the issueToken is different from the transfer. When we issue a token to an address, this usually requires some additional CKB for the token cell. I guess this is why sudt.transfer provide an optional parameter capacity to transfer CKB in a transaction.

I tried to create a CKB transfer using the method transfer in common-scripts/secp256k1_blake160, it will burn the SUDT cells to provide enough capacity. What's the recommended way to create a simple CKB transfer transactions but filtering out input cells that have a type script?

Which cellProvider in the txSkeleton in use? I recommend using the secp256k1.Collector to avoid collecting SUDT cell as transfer inputs

The transfer method in common-scripts/sudt accepts any address in fromInfos, but it will not use the address to find input cells with the corresponding lock script. Instead, the method will use the args as a public key hash, and use it to find cells locked by the builtin system lock scripts. It seems a unnecessary dependency on the system lock scripts.

This is because when common-scripts needs to know how to setupInputCell, For an unregistered lock, Lumos does not know how to prepare the signing entry