spend aggregated inputs

overview

the millix node user interface operates with an active wallet that is loaded when the node starts. the active wallet is associated with a key identifier and all the addresses associated with that key identifier. the sum of all the funds sent to those addresses that have not yet been spent (unspents) form the balance of available funds for the wallet. from this perspective, the balance of a particular address is less significant than the wallet balance of all the addresses added together.

when the user sends millix, the millix node user interface decides which available unspents will be used to fund the transaction. the millix node user interface only allows one destination address per transaction. the logic in this document is only applicable to the millix node user interface. it does not apply to transactions that are constructed in json with specific unspents and submitted via API

problem: aggregating and selecting unspents

without aggregating unspents to fund transactions, users would have to fund each new transaction strictly with the balance of an individual address. this would mean a user couldn't send a transaction larger than the balance of any individual address, even if their wallet balance was adequate. this becomes even less convenient if the user has unspents that are approaching expiration but are unavailable to fund a transaction because they exist on an address whose balance is smaller than the size of the transaction.

solution: first in first out

there are a variety of strategies used by cryptocurrency wallets to optimize how unspents are selected to fund transactions. traditionally it's been a difficult problem because each strategy has costs and benefits; so much so that it's not uncommon for the strategy to merely be selecting unspents randomly.

the millix user interface uses a first-in-first-out, random strategy with a variation depending on the recipient of the transaction. in other words the oldest unspents are used first, and if a group of unspents are the same age, random selections are made from that group until the amount of the selected unspents meets or exceeds the amount being sent by the transaction.

if the user is not sending millix to themself the unspents cannot be expired. if the user is sending millix to themself (based on the key indicator of the receiving address and the active key identifier being run by the node) the selected unspents can be expired.