To protect users who are not using opreturn we prevent any use of z_sendmany
with absurd fees if opreturn is not being used, so this change only affects
users who are adding opreturn data. Since there is no way to currently send
opreturn data via a GUI this still protects all GUI users from absurd fees
while allowing CLI users to decide to use higher fees.
By taking a wallet lock first and then main later we run into
a potential deadlock :
2024-09-13 11:14:37 POTENTIAL DEADLOCK DETECTED
2024-09-13 11:14:37 Previous lock order was:
2024-09-13 11:14:37 (1) cs_wallet wallet/wallet.cpp:985
2024-09-13 11:14:37 (2) cs_main wallet/wallet.cpp:890
2024-09-13 11:14:37 Current lock order is:
2024-09-13 11:14:37 (2) cs_main wallet/wallet.cpp:2845
2024-09-13 11:14:37 (1) cs_wallet wallet/wallet.cpp:2845
We do not seem to need this lock for the entire DecrementNoteWitnesses function,
we need it only when calling GetSaplingSpendDepth. Also protects against
the case in the future where some code without cs_main calls GetSaplingSpendDepth.
Another possibly better approach would be to take a lock inside
GetSaplingSpendDepth since we want the lock to apply to as little
code as possible and it is GetSaplingSpendDepth that calls GetDepthInMainChain
which requires a cs_main lock .
The previous error message was incorrect, it could be too many inputs
or a combination of too many inputs and outputs and also did not report
the estimated size.
These NU's are always active for Hush Arrakis Chains so this code only serves
to slow down all operations by constantly being checked. So we disable them
which will speed up syncing, mining and creating transactions.
Duke