Open garyyu opened 5 years ago
As far as the boolean is concerned (selection_strategy_is_use_all
), I think it's fair to change it to use the actual type of the strategy for backwards compatibility reasons.
UTXO selection strategies are notoriously difficult and optimise for different objectives.
As a wallet developer, rather than being provided with a set of fixed strategies via the API, I'd much prefer to have full control of the strategies I choose to develop for my specific wallet and use cases. From my side, I think it would be more useful to provide a 'toolbox' via the API that wallet developers could use to design their own strategies. For example being able to select specific outputs from a user's wallet to build transactions with, or being able to select outputs according to certain criteria.
/grin-wallet
could use the same API to build a couple of basic reference strategies, and 3rd party wallets would be free to experiment and use whatever strategies they feel like using.
@lehnberg pls make it clear what's a 'toolbox' here?
I'm proposing to enhance this selection_strategy_is_use_all
which is currently a boolean type. What's your 'toolbox' to apply in a selection strategy?
@garyyu
As a third party wallet developer, it would be nice if the API would allow me to obtain information about a user's UTXO set and allow me to send granular selection instructions (i.e. I'd like to build a transaction with output a
, output b
, output e
and output g
), so that I can devise my own selection strategies in my wallet rather than having the grin core development team doing so on my behalf.
I feel it's a good time to consider more about the
selection_strategy
, better to have the updated one in1.1.0
milestone to avoid another incompatibility in the future.Currently our
selection_strategy
support 2:all
andsmallest
:And current API use a
bool
type for thisselection_strategy
:The explain of this parameter:
all
, attempt to use up as many outputs as possible to create the transaction, up the 'soft limit' ofmax_outputs
. This helps to reduce the size of the UTXO set and the amount of data stored in the wallet, and minimizes fees. This will generally result in many inputs and a large change output(s), usually much larger than the amount being sent.smallest
, the transaction will include as many outputs as are needed to meet the amount, and no more, starting with the smallest value outputs.I would propose to add a new one:
biggest
, the meaning of thisbiggest
strategy:biggest
, the transaction will include as many outputs as are needed to meet the amount, and no more, starting with the biggest value outputs.The use case is for splitting, in case we want to have more UTXO sets for paying out (for example miners payout in a pool), to avoid locking the whole wallet, the better way is to start selection from biggest value outputs, instead of from smallest.
Do you have more
selection_strategy
to be requested in this version? before I start giving a PR on this feature.