Reconsider the UTXO sorting algorithm in DataSource.getUtxos()

[ShookLyngs]

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 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]

• link Building BTC TX with an address having excessive UTXOs takes forever #173 (comment)