I'm not comfortable with sending up to 25 bigs txs (actually can even be more) without the user being told anything about this. This might be a tradeoff a wallet would want to do for the sake of simplicity but it being the default behavior is unexpected for a wallet library. It's nice to have the feature, it's not to have any vibe coded app potentially send lots of txs without the dev being aware this might happen. If you feel like prompting the user is not necessary for your app it's fine (fees are low, and Cashtab doesn't show the fee anyway) but it's the exception and not the norm, most wallet will show this info and ask for confirmation.

I would draw the line here: don't assume what user/dev will accept to happen with their money.

I agree that the right move in the end is to have more utxo selection strategies, and I also agree that this is a useful feature (especially for cashtab), just not a sane default.

Ok it's likely too technical and hard to determine a value

I removed the 25 thing, which is actually misleading. It's an "AI trying to provide some kind of abundance of caution" bug.

the consolidateUtxo method is already a while loop; if it is called at all, it will consolidate all the utxos.

It should always take only one pass. In some kind of edge case where we are still getting maxTxSersize error now after a consolidate, build() would throw.

I would draw the line here: don't assume what user/dev will accept to happen with their money.

I think this is a reasonable line. What build() does is fulfill the specified action. Perhaps it fulfills it in an unexpected way, but it is some edge case where this type of fulfillment is undesired. The user would want total control over their utxo set, would want to fulfill the original action (which would require some level of consolidation no matter what).

I lean toward this as default since

• I've gotten the complain dozens of times, and it has never been from someone who wanted more granular control of the UTXO set, always from someone who just wants it to work and doesn't understand the error
• If it were an option, I would need to enable it in all my implementing apps
• Outside of Electrum-ABC or mb some other future power-user app, I don't think any user-facing wallet app should ever communicate to the user anything about the UTXO set. A big advantage of XEC over account based chains is that stuff "just works." The byzantine attempt to explain fee failures to users of ETH has never led to happy users. The fee rate is a configurable param in ecash-wallet, tho it defaults to the minimum.
• Practically speaking, I do not think there is a single user who would require more than say 3 rounds of consolidation so send a given action their wallet can afford. Huge UTXO sets are today coming from:

1. XECX payouts (which are daily, so usually takes years of inactivity for this to surface a maxTxSersize error)
2. Firma payouts (same)
3. Technical users who are creating machine gun txs for various purposes (if they want better UTXO control, then ecash-wallet's accumulative default is already not an ideal default)

... that said I don't mind too much either way, i.e. adding it as a setting isn't an insurmountable objection. I could do something like, update the maxTxSersize error msgs to recommend calling consolidateUtxos or to call build() with autoConsolidate: true

The original const and implementation was confusing; the consolidateUtxos method already uses a while loop and already makes as many txs as necessary.

One thing to keep in mind is that the wallet will indeed throw if it does not have enough XEC to cover the required fee of all the txs.