search

iotaledger / iota-sdk

The IOTA SDK provides developers with a seamless experience to develop on IOTA by providing account abstractions and clients to interact with node APIs.
Apache License 2.0
56 stars 41 forks source link

Expose locked_outputs to users? #1549

Open Thoralf-M opened 10 months ago

Thoralf-M commented 10 months ago

Description

Expose locked_outputs or basically a duplication of it to users, so they manually can lock some outputs they don't want to be consumed in transactions? Having two methods like .lock_output(output_id), .unlock_output(output_id) that add/remove this output id to/from the locked_outputs field of the wallet.

Motivation

For example one has a basic output with some metadata feature that one would like to keep and not consume in other transactions, then it would be nice if one can just call .lock_output(output_id), .unlock_output(output_id) to make it not available for transactions or later available again.

Requirements

  1. Add .lock_output(output_id) or .lock_output(output_id, "my precious metadata output".to_string()) and .unlock_output(output_id) which make outputs not or available to the input selection
  2. Make sure that users don't mess up transactions and that https://github.com/iotaledger/iota-sdk/blob/8b55ee58ff725864e78ec8c1ddc154b95f54c9de/sdk/src/wallet/core/builder.rs#L276 isn't messing up user locked outputs

Open questions (optional)

Currently locked_outputs is a HashSet locked_outputs: HashSet<OutputId> that is automatically filled/cleared based on selecting inputs/transactions, if we allow to just unlock any output id there, users could mess it up (unlock outputs that are already used as inputs in txs) which could lead to conflicting transactions. And user defined outputs would be also removed automatically here https://github.com/iotaledger/iota-sdk/blob/8b55ee58ff725864e78ec8c1ddc154b95f54c9de/sdk/src/wallet/core/builder.rs#L276 if that's not changed. Therefore it might make sense to create a new HashSet for user defined locked outputs to keep them separated. Or maybe a HashMap<OutputId, Reason> would be better? Then users could even specify a reason for what they locked an output. Reason could be an enum like this

pub enum Reason {
    // Used as input in a transaction.
    TransactionInput,
    // Locked by the user.
    Custom(String),
}

Then .lock_output(output_id, "my precious metadata output".to_string())

Are you planning to do it yourself in a pull request?

No.

Thoralf-M commented 7 months ago

As a simpler but not so convenient alternative, forbidden_inputs could be added to the TransactionOptions