Skip to content

Improve default wallet ChangeOwner selection #3316

Open
@StephenButtolph

Description

@StephenButtolph

Context and scope

The wallet is essentially defined by a set of keys. For example, keyA, and keyB. Any UTXOs that are spendable by keyA, keyB, or both keyA and keyB are considered "owned" by a wallet defined by {keyA, keyB}.

UTXOs are essentially defined by an asset, amount, and a set of owners. The owners
are themselves a set of keys and a threshold.

Therefore, we can have a wallet with keyA and keyB. Along with utxoA that has 5 AVAX and is owned by keyA and utxoB that has 10 AVAX and is owned by keyB.

If the user of this wallet wanted to send 12 AVAX to keyC, then it would need to consume both utxoA, and utxoB. However, the wallet has now consumed 15 AVAX... We don't want to send 12 AVAX to keyC, so 3 AVAX (ignoring tx fees) needs to be returned to the wallet... but who should own this new output? Sending the 3 AVAX output to keyA, keyB, or both keyA and keyB all seem fairly reasonable on the surface.

The way the wallet handles this currently, is by allowing the user of the wallet to explicitly set who to send the remaining funds to and defaulting to randomly selecting one of the keys that is owned in the wallet to send the funds back to.

Rather than randomly selecting one of either keyA or keyB, it seems like keyB should be used to return the 3 AVAX because it contributed 10 AVAX in the transaction and keyA only contributed 5. This would prevent the situation where a key with a large amount of AVAX has the funds get transferred, by default, to an address with a small (or no) amount of AVAX.

Discussion and alternatives

An possible alternative would be to require specifying the ChangeOwner if the wallet has multiple keys - but I worry that this would be pretty tedious (and having required options seems odd).

Open questions

Any other ideas for change owner selection?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Backlog 🧊

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions