To use the script:
./contrib/avg_blocktime.pl DRAGONX
It has some default block heights defined, if you want custom ones
than those are given as 2nd and 3rd arguments. Currently the script
prints out:
Avg blocktime over 3000 blocks = 36.0526666666667
So with this evidence it seems that DRAGONX has the correct average
blocktime and network hashrate.
This commit removes the CLI option -opretmintxfee, makes it always
enabled, changes the required fee rate and changes which OP_RETURNS
get "amnesty" and do not need to pay this fee rate.
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.
Technically we should take this lock but it has never been there before
and it leads to potentially large slow downs when mining with multiple cores.
We see basically the same hashrate for a single core if we have the lock or
not and that makes sense, since there is only one core, there are no other
mining threads that have to wait. But on one particular CPU I saw a 6% slower
hashing when mining with 2 threads and 35% slower with 3 threads.
This change also means debug builds will coredump if mining is enabled.
Technically we should take this lock but it has never been there before
and it leads to potentially large slow downs when mining with multiple cores.
We see basically the same hashrate for a single core if we have the lock or
not and that makes sense, since there is only one core, there are no other
mining threads that have to wait. But on one particular CPU I saw a 6% slower
hashing when mining with 2 threads and 35% slower with 3 threads.
This change also means debug builds will coredump if mining is enabled.
Our code requires sapling activation at height 1 so we can simplify this function
which should lead to some performance improvements since it is called from many
places, including mining code.
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
Without it we get an AssertLockHeld when calling GetKeyPoolSize .
We could probably make this lock apply to less code, possibly only
the single line that calls GetKeyPoolSize() needs it.
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 .
This allows us to see function names in a backtrace when AssertLockHeld
gives us an assert, which is helping to debug our deadlock bug.
This code should be improved to only do this for debug builds.
This should lower the main thread's likelihood to immediately reacquire
cs_main after dropping it, which should help ThreadNotifyWallets and the
RPC methods to acquire cs_main more quickly.
Ported from ZEC commit e2cd1b761fe556bc6d61849346902c3611530307
Hush and DragonX do not have the same requirements for which nodes they
should talk to because they don't necessarily have consensus changes at
the same time. For instance, 3.10.0 was a consensus change for Hush but
not DragonX. This commit changes things so that Hush nodes will no
longer talk to old nodes that are not consensus compatible but leaves
things the same for DragonX mainnet, which has never had a consensus
change.
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.
Duke