The current sorting algorithm used in the DataSource.getUtxos() API is: oldest comes first, newest comes last. It means when collecting UTXOs for paying transaction fees, the oldest UTXOs always get selected first.
This pattern can be problematic when constructing a transaction with an address that has many tiny and old UTXOs. These tiny, old UTXOs are hard to spend because including them in the transaction will cost more in network fees than the value contained in the UTXOs. To somewaht avoid the "value-cost-trap" issue, it is best to include the largest UTXOs in the transaction whenever possible.
Possible resolvers
Refactor the sorting algorithm
We can change the sorting algorithm in the mentioned code to: largest comes first, smallest comes last.
The benefit is that the success rate of transaction construction should rise, as tiny UTXOs will have less chance to be included for fees, based on the condition that the target address contains both large and tiny UTXOs. However, this sorting algorithm also comes with downsides. One of them being that there may be more transaction chains constructed on-chain, if an address has a large UTXO that contains high value, the UTXO can be spent over and over.
Add a sort option
We can add an option sort to the DataSource.getUtxos() API, so then the caller can desice which sorting algorithm to use. In normal transfers, the user can just use the oldest UTXOs for fee, and when sometimes the "value-cost trap" issue is occured, the user can manually specify and change the sorting algorithm, to use the largest UTXOs for fee.
Flouse
commented
3 months ago
Issue
The current sorting algorithm used in the DataSource.getUtxos() API is: oldest comes first, newest comes last. It means when collecting UTXOs for paying transaction fees, the oldest UTXOs always get selected first.
Ref: https://github.com/ckb-cell/rgbpp-sdk/blob/develop/packages/btc/src/query/source.ts#L81-L88
This pattern can be problematic when constructing a transaction with an address that has many tiny and old UTXOs. These tiny, old UTXOs are hard to spend because including them in the transaction will cost more in network fees than the value contained in the UTXOs. To somewaht avoid the "value-cost-trap" issue, it is best to include the largest UTXOs in the transaction whenever possible.
Possible resolvers
Refactor the sorting algorithm
We can change the sorting algorithm in the mentioned code to: largest comes first, smallest comes last.
The benefit is that the success rate of transaction construction should rise, as tiny UTXOs will have less chance to be included for fees, based on the condition that the target address contains both large and tiny UTXOs. However, this sorting algorithm also comes with downsides. One of them being that there may be more transaction chains constructed on-chain, if an address has a large UTXO that contains high value, the UTXO can be spent over and over.
Add a
sortoptionWe can add an option
sortto the DataSource.getUtxos() API, so then the caller can desice which sorting algorithm to use. In normal transfers, the user can just use the oldest UTXOs for fee, and when sometimes the "value-cost trap" issue is occured, the user can manually specify and change the sorting algorithm, to use the largest UTXOs for fee.