user5520: I created a bidding war in Plutus Playground between 5 wallets.
Wallet 2 bids first and then is outbid by Wallet 3 and got refunded as usual. Later on when Wallet 2 went to bid again with a higher amount only the first unspent Tx was used as an input.
However later on Wallet 3 was outbid by Wallet 4 which was outbid again a few slots after. Wallet 4 then placed another bid, but this time when Wallet 4 placed its bid, it used 2 inputs (the previous change amount plus the refunded amount) to cover the bid.
In both scenarios, both wallets had enough in their first unspent Tx after their initial bid to cover the next bid they put in. This would make me think that the wallets don't necessarily spent their lowest UTxO first since only one wallet used their refunded bid in addition to their first unspent Tx.
Why is this?
Images below show what happened.






user382: How coins are selected isn't defined in the playground. Probably the easiest algorithm is largest utxo first (since it's a playground you don't need to worry about fragmentation). If that's the case then as long as the initial change is large enough for a bid the tx wouldn't need to consume both inputs.
In practice on chain the user (or more likely the user's wallet) is responsible for choosing the utxo that is the input for the transaction. Cardano wallet for example uses a random coin selection algorithm. Other wallets use a largest utxo algorithm and others may have something entirely different. From the perspective of plutus though the tx outputs into the contract is all it cares about though.

5520: <p>I created a bidding war in Plutus Playground between 5 wallets.</p>
<p>Wallet 2 bids first and then is outbid by Wallet 3 and got refunded as usual. Later on when Wallet 2 went to bid again with a higher amount only the first unspent Tx was used as an input.</p>
<p>However later on Wallet 3 was outbid by Wallet 4 which was outbid again a few slots after. Wallet 4 then placed another bid, but this time when Wallet 4 placed its bid, it used 2 inputs (the previous change amount plus the refunded amount) to cover the bid.</p>
<p>In both scenarios, both wallets had enough in their first unspent Tx after their initial bid to cover the next bid they put in. This would make me think that the wallets don't necessarily spent their lowest UTxO first since only one wallet used their refunded bid in addition to their first unspent Tx.</p>
<p>Why is this?</p>
<p>Images below show what happened.</p>
<p><a href="https://i.stack.imgur.com/tXxMb.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/tXxMb.jpg" alt="Wallet 2 gets outbid and refunded" /></a></p>
<p><a href="https://i.stack.imgur.com/dpbH1.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/dpbH1.jpg" alt="Wallet 4 makes initial bid" /></a></p>
<p><a href="https://i.stack.imgur.com/dkSEY.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/dkSEY.jpg" alt="Wallet 4 gets outbid and refunded" /></a></p>
<p><a href="https://i.stack.imgur.com/yvWFA.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/yvWFA.jpg" alt="Wallet 2 makes another bid with only the first UTxO" /></a></p>
<p><a href="https://i.stack.imgur.com/TDfKV.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/TDfKV.jpg" alt="Wallet 4 makes a bid using both UTxOs" /></a></p>
 382: <p>How coins are selected isn't defined in the playground. Probably the easiest algorithm is largest utxo first (since it's a playground you don't need to worry about fragmentation). If that's the case then as long as the initial change is large enough for a bid the tx wouldn't need to consume both inputs.</p>
<p>In practice on chain the user (or more likely the user's wallet) is responsible for choosing the utxo that is the input for the transaction. Cardano wallet for example uses a random coin selection algorithm. Other wallets use a largest utxo algorithm and others may have something entirely different. From the perspective of plutus though the tx outputs into the contract is all it cares about though.</p>
