Set feeCharged with the min fee for core to accept a transaction
#2624
Conversation
| IMPLICIT_UNSAFE_UINT128_OPS operator uint8_t() const; | ||
| IMPLICIT_UNSAFE_UINT128_OPS operator uint16_t() const; | ||
| IMPLICIT_UNSAFE_UINT128_OPS operator uint32_t() const; | ||
| IMPLICIT_UNSAFE_UINT128_OPS operator uint64_t() const; | ||
|
|
||
| // Bitwise Operators | ||
| uint128_t operator&(const uint128_t & rhs) const; |
There was a problem hiding this comment.
We probably shouldn't allow any of these templated operators, because they all violate the principle of "easy to use correctly and hard to use incorrectly". You already did this for the non-member arithmetic operators, but it also applies to (for example) the non-member bitwise operators and the member arithmetic and bitwise operators. This isn't necessarily a complete list.
There was a problem hiding this comment.
yeah I only changed the ones that could potentially be used in the bug I fixed. We're going to have to take a much blunter instrument for the next round of changes to that class but that's outside of the scope of that PR.
There was a problem hiding this comment.
Alright I'm fine with that. Let's open an issue for this.
MonsieurNicolas
force-pushed
the
minFeeError
branch
from
5ed002a
to
0e5c2a1
Compare
|
r+ 0e5c2a1 |
29fd9c9 references Herder which is not available when building without tests
MonsieurNicolas
force-pushed
the
minFeeError
branch
from
0e5c2a1
to
8f356f7
Compare
|
had to disable a check in |
|
I also added a commit to fix the build (doesn't compile when tests are disabled) |
|
r+ 8f356f7 |
Description
Resolves #2505
replaces #2521
This PR tweaks the behavior when checking validity such that
feeChargedin theTransactionResultis always set with the minimum fee that core expects for that transaction to be accepted in the transaction queue and to pass validity in general.Core was almost doing this, this PR makes it that it's doing it consistently for all instances of
txINSUFFICIENT_FEE.I decided to not touch the code at all in the "apply" case even though I think that with today's logic it's actually not possible to reach some of the conditions that are in the codebase. Given how critical fees are in the system, I figured this was the more conservative approach and that has less chance of breaking in the future.