[amount] Add support for negative fee rates

[maflcko]

Currently negative fee rates are not supported on archs of 64-bit or more

[laanwj]

Negative fee rates imply that you pay a smaller, more negative fee the larger the transaction? What do negative fees even mean, steal from the miner? Or is this so that anti-transactions of negative size pay a positive fee?

I'd say this is an edge case better to get rid of (e.g. assert or throw an error).

[sipa]

Uninformed guess: maybe they are relevant for priotizetransaction?

[laanwj]

According to @MarcoFalke they already don't work on 64-bit architectures, which is probably 90%+ of all nodes. Better to remove it for 32 bit as well.

[maflcko]

@sipa is correct

@laanwj I have pushed the fix as a second commit, so the travis result can be compared. The fix is probably a lot smaller than the fix which removes support.

[laanwj]

Instead of the temporary variable, why not just:

nSatoshisPerK = nFeePaid * 1000 / static_cast<int64_t>(nSize);

Also at least theoretically you should handle the case where nSize is outside the range of int64_t, though I doubt someone will ever care about transactions that large.

[maflcko]

If it is used more than once, you'd rather want to do the cast only once. I guess an alternative would be to change it in the constructor arguments, but that is less verbose, imo.

[laanwj]

I guess an alternative would be to change it in the constructor arguments

I thought of that, but didn't mention it at second thought. Before you know it people will want full support for negative sizes as well. The appropriate type is size_t.

[maflcko]

This would require a cast in 4 places instead of two (see diff below) but I am happy to apply the diff an squash. Please let me know how to proceed so we can finalize this.

diff --git a/src/amount.cpp b/src/amount.cpp
index 7b8618d..3966c5f 100644
--- a/src/amount.cpp
+++ b/src/amount.cpp
@@ -13,8 +13,7 @@ CFeeRate::CFeeRate(const CAmount& nFeePaid, size_t nBytes_)
 {
     assert(nBytes_ <= uint64_t(std::numeric_limits<int64_t>::max()));
-    int64_t nSize = int64_t(nBytes_);

-    if (nSize > 0)
-        nSatoshisPerK = nFeePaid * 1000 / nSize;
+    if (int64_t(nBytes_) > 0)
+        nSatoshisPerK = nFeePaid * 1000 / int64_t(nBytes_);
     else
         nSatoshisPerK = 0;
@@ -24,9 +23,8 @@ CAmount CFeeRate::GetFee(size_t nBytes_) const
 {
     assert(nBytes_ <= uint64_t(std::numeric_limits<int64_t>::max()));
-    int64_t nSize = int64_t(nBytes_);

-    CAmount nFee = nSatoshisPerK * nSize / 1000;
+    CAmount nFee = nSatoshisPerK * int64_t(nBytes_) / 1000;

-    if (nFee == 0 && nSize != 0) {
+    if (nFee == 0 && int64_t(nBytes_) != 0) {
         if (nSatoshisPerK > 0)
             nFee = CAmount(1);

[laanwj]

Ok, at least document this then, for example in the doc comment of the constructor. It's extremely unintuitive to me and probably to others reading this code as well.

[maflcko]

Ok, will add the doc later...

[morcos]

ping @sdaftuar

[sdaftuar]

I think it's probably better to fix support for negative fee rates on 64-bit platforms, because (a) fixing the prioritisetransaction RPC to disallow negative feerates would be difficult/annoying because fee deltas can be stored prior to transaction acceptance, (b) it would be counterintuitive if you called prioritisetransaction with -X and then later with X but didn't get back to where you started, and (c) I think there might be legitimate reasons to want to keep an ordering of transactions you don't want to mine right now (which you'd lose if you tried to floor everything at zero, which is the easiest reasonable alternative I can come up with).

But to be fair, I'm surprised that no one has complained about this before, because as far as I can tell, up until 0.12, if you used prioritisetransaction to apply a negative feerate, then the mining code would immediately select it as a super-high-fee transaction. (I stumbled upon this behavior while working on #7063.)

So, concept ACK. I agree with @laanwj's comment about the cast. Also, I think it probably makes most sense to enforce the property that CFeeRate(X).GetFee(size) == -1 * CFeeRate(-X).GetFee(size); if everyone agrees, then we should make the special case rounding recently introduced (where we return CFeeRate(1)) also apply in the negative fee rate case.

Also, we should add a unit test that exercises the constructor CFeeRate(const CAmount& nFeePaid, size_t nSize_) that is changed in this PR.

[maflcko]

I think it probably makes most sense to enforce the property that CFeeRate(X).GetFee(size) == -1 * CFeeRate(-X).GetFee(size);

Makes sense, done.

add a unit test that exercises the constructor CFeeRate(const CAmount& nFeePaid, size_t nSize_)

Done.

[maflcko]

Before on 64-bit:

test/amount_tests.cpp(33): error: feeRate.GetFee(1) == -1 has failed [18446744073709550 != -1]
test/amount_tests.cpp(34): error: feeRate.GetFee(121) == -121 has failed [18446744073709430 != -121]
test/amount_tests.cpp(35): error: feeRate.GetFee(999) == -999 has failed [18446744073708552 != -999]
test/amount_tests.cpp(36): error: feeRate.GetFee(1e3) == -1e3 has failed [18446744073708551 != -1000]
test/amount_tests.cpp(37): error: feeRate.GetFee(9e3) == -9e3 has failed [18446744073700551 != -9000]
test/amount_tests.cpp(53): error: feeRate.GetFee(8) == -1 has failed [18446744073709550 != -1]
test/amount_tests.cpp(54): error: feeRate.GetFee(9) == -1 has failed [18446744073709550 != -1]
test/amount_tests.cpp(58): error: CFeeRate(CAmount(-1), 1000) == CFeeRate(-1) has failed

After:
tests pass

[laanwj]

utACK facf5a4

[jtimon]

Couldn't have we just removed this special case from here (ie move this check to the callers that need it)?
I know that would be more disruptive, but it will also make increasing the internal precision easier later.

[maflcko]

Sure!

I am only aware of the wallet using it:

bitcoin/src/wallet/wallet.cpp

Line 2335 in 430fffe

if (nFeeNeeded == 0) {

[jtimon]

Oh, that's great. Moving from nSatoshisPerK to 1 was already and step forward. But I've strong reason to believe that this special case was the most important impediment for not being able to "easily" do more than *2 on internal precision in #7731(in fact, I don't think it would pass all the tests if I rebased this now due to this change).

If you create a PR to move the special case to the wallet only, please ping me for review, I am very interested in seeing that happening. Looking at the code you link to, it looks like that part can actually be simplified as a result, instead of complicating it. But tests will break...

[jtimon]

After this, the following change will fail the new tests in amount_tests.cpp: 5ca2473

This is a mystery to me, can anybody help me understand?
I get the same errors that MarcoFalke gets "Before on 64-bit:", do I have to do something locally on 64 bits linux?