You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
This issue has become stale because it has been open 60 days with no activity. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.
Context and scope
The wallet is essentially defined by a set of keys. For example,
keyA
, andkeyB
. Any UTXOs that are spendable bykeyA
,keyB
, or bothkeyA
andkeyB
are considered "owned" by a wallet defined by{keyA, keyB}
.UTXOs are essentially defined by an
asset
,amount
, and a set ofowners
. Theowners
are themselves a set of keys and a threshold.
Therefore, we can have a wallet with
keyA
andkeyB
. Along withutxoA
that has5
AVAX and is owned bykeyA
andutxoB
that has10
AVAX and is owned bykeyB
.If the user of this wallet wanted to send
12
AVAX tokeyC
, then it would need to consume bothutxoA
, andutxoB
. However, the wallet has now consumed15
AVAX... We don't want to send12
AVAX tokeyC
, so3
AVAX (ignoring tx fees) needs to be returned to the wallet... but who should own this new output? Sending the3
AVAX output tokeyA
,keyB
, or bothkeyA
andkeyB
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
orkeyB
, it seems likekeyB
should be used to return the3
AVAX because it contributed10
AVAX in the transaction andkeyA
only contributed5
. 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?
The text was updated successfully, but these errors were encountered: