Previous discussion: #10015

Sad that #10015 never landed. fwiw not changing the error message here - I think "insufficient funds" is the right message to return if you're unable to produce a transaction that would be accepted by your mempool.

So the change here will be:

• Before a user would see their balance deplete, until they run out of funds (as their change is ignored, see Could the wallet count unconfirmed non-mempool change? #11887), then coin selection will fail. Previously created txs will likely broadcast at some point and the balance returns to normal.
• Now a user would see coin selection fail, but have an accurate balance.

In both cases the user will see coin selection fail, so it seems the underlying user problem still exists. Though, it is probably fine to postpone a fix for that until after #11887, in which case this pull can be reverted again.

Concept ACK

I don't think it makes sense for the wallet to by default make transactions that won't be relayed immediately. The current behavior also leads to user confusion about their balance.

I think "insufficient funds" is the right message to return if you're unable to produce a transaction that would be accepted by your mempool.

I think "insufficient funds" is too generic of an error message for coin selection failures as there are a ton of different reasons why coin selection might fail. I would like to have more granular error messages, but changing that is orthogonal to this.

ACK 9ca1de5

I've marked the remaining typos with 👀

re-ACK da2bc86 only change is fixing typos in tests 🎏

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK da2bc865d644f6be748c305556bdd02f02d1b161 only change is fixing typos in tests 🎏
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUgIugv/ddcX8zoLuze/7EuMxEnxlwIMKPYVFfzrFX2cLnCnpf+jIqwArqhmM5h8
yWrv6P877baXdFizgrlGQu5gMEFDPE8ZrXZKmzN1sg0dj+nc4W25zNSrfe9VP4Nw
AyumBUkzjznXrktn2ICNE7d3Ye2BbSLNbfcXVGmCgUq+ilwvmXoSvVU5SqUs6tlP
/yQQUxlR0Nn6aj0ABcbPhJOdZO8JvgVA1o4hPIPzDwEqmzsDDaqnQrHlJfhRHxU9
mTsaR9fX6zJxjdyrUdQfpP9vO2jIv9Fdv791SD3+ECIwAOsXIbSnrj3r3rhQ1DPu
aKk45J6gFDqt9Ls4Q5rCm6lR+9Zt4PzyjW9iQR41NenLZlXJh9NeK496wkioZm0S
+N7+nwrJQR6Z2A09KxsVKOXM95jJHmrsFGNR7K85GDeXWtm1gGjKUnImzmyvGpY/
8/cUPqXq5PSnl0vh+9CbXAF3uszowQWwo4+gXJCkd3KKjezXQWruzOieEJod2yeZ
ADGknmuH
=K1MH
-----END PGP SIGNATURE-----

re-ACK da2bc86

Late ACK, thanks for updating this!

We've been running with this parameter set to true ever since we discovered this flag, because one day we got bitten by this in production and realized this problem.