bumpfee RPC not working as expected since 0.19.0.1 #18240

Expected behavior Transaction should be replaced with another with bumped fees (lower confTarget) as it was in <=v0.18.

Actual behavior Transaction was sent with sendmany request with replaceable=true and conf_target=3. Then I've tried to override confTarget to 1 with RPC. Assuming that I haven't specified paytxfee value in node's config.

curl -u myusername:pass --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "bumpfee", "params": ["hash"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

Response:

{
  "txid": "hash",
  "origfee": 0.00000247,
  "fee": 0.00001237,
  "errors": [
  ]
}

Then I got this in logs: Fee Calculation: Fee:1050 Bytes:168 Needed:1050 Tgt:0 (requested 0) Reason:"PayTxFee set" Decay 0.00000: Estimation: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out) Fail: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out)

Some interesting observation: I was trying to do this with bitcoin-cli without specifying confTarget option and it has succeeded: bitcoin-cli bumpfee <hash>

But with confTarget option it fails despite success response from node: bitcoin-cli bumpfee <hash> "{\"confTarget\": 1}"

The same issue even if I'm not providing confTarget: curl -u myusername:pass --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "bumpfee", "params": ["hash"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

To reproduce Make a send with conf_target greater than 1 and try to bump fees.

System information

Official Bitcoin Core v0.19.0.1 CentOS Linux 7.7.1908

@yurayakimenko can you try with the master branch or the pre-release v0.19.1?

Could this be related to #17643? cc @instagibbs

@yurayakimenko sorry could you be slightly more specific on how you trigger this? The specific case where might be a weird interaction with fee estimation and the code making it slightly harder to write a test for it.

1. on mainnet, send a transaction with confTarget > 1
2. bumpfee with confTarget of 1?

@Sjors Unfortunately, we are using this node in production. It would be easier to anyone confirm this issue with provided "steps to reproduce".

And you're saying you didn't set PayTxFee but the error says PayTxFee set?

1. on mainnet, send a transaction with confTarget > 1
2. bumpfee with confTarget of 1? @instagibbs 1 - Yes, 2 - Yes.

Nothing specific. Just regular transaction that I had sent with sendmany method. bumpfee RPC call returned no errors and the hash of new transaction.

paytxfee is not specified. This line is the same as here - https://github.com/bitcoin/bitcoin/blob/master/share/examples/bitcoin.conf#L134

I'm using exact the same config with v0.18.* and everything was working as expected.

What's the error when adding the transaction to the mempool?

@instagibbs That was the only log entry after bumping fee:

Fee Calculation: Fee:1050 Bytes:168 Needed:1050 Tgt:0 (requested 0) Reason:"PayTxFee set" Decay 0.00000: Estimation: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out) Fail: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out)

Seems like fee was increased, but it's not reacting to changes.

@instagibbs Seems like it's not adding to mempool at all. At least there is no info about this in logs.

Sigh, we really need a "mock fee estimation" RPC call for test writing. I'm trying to replicate.

If you call bumpfee with "2" as the confTarget, does that work? I'd expect it to break identically.

If you call bumpfee with "2" as the confTarget, does that work? I'd expect it to break identically. @instagibbs It's failing anyway, regardless any pair of confirmation targets, assuming I always stick with rule "bumped confTaget < transaction confTarget". I've tried to send with confTarget=6 and to bump it to 2 or 3. All the same.

The only one working case is by using bitcoin-cli: bitcoin-cli bumpfee <hash>

having trouble reproducing. Wrote a test scenario which ensures feerates are different for different confTargets:

diff --git a/test/functional/feature_fee_estimation.py b/test/functional/feature_fee_estimation.py
index d2d41b120..a26e4e947 100755
--- a/test/functional/feature_fee_estimation.py
+++ b/test/functional/feature_fee_estimation.py
@@ -248,6 +248,17 @@ class EstimateFeeTest(BitcoinTestFramework):
         self.log.info("Final estimates after emptying mempools")
         check_estimates(self.nodes[1], self.fees_per_kb)
 
+        from pdb import set_trace
+        set_trace()
+        print("Let's try to bump some stuff")
+
+        # Send transaction with high confTarget
+        txid = self.nodes[0].sendtoaddress(self.nodes[0].getnewaddress(), 1, "", "", False, True, 100)
+        # Now bump transaction with confTarget lower
+        txid2 =  self.nodes[0].bumpfee(txid, {"confTarget":1})["txid"]
+        assert txid2 in self.nodes[0].getrawmempool()
+        assert txid not in self.nodes[0].getrawmempool()

Are you able to consistently reproduce this? I'm willing to crawl through some logs if you're willing to share them privately via e-mail.

@instagibbs I've sent you email, mentioned as yours in GitHub profile.

@instagibbs UPD: Bumped transaction is entering mempool and not failing. But it always getting confTarget=0 despite requested value. Our business logic requires to bump fee to confTarget=2 So it seems like RPC is ignoring it.

Ok! That's a very different(And more probable!) error.

Ok my guess is that bumpfee and related bump logging is just not great, and things are logically ok.

bumpfee internally is doing some calculations of its own, then shoving "intent" into CWallet::CreateTransaction. The fee logging posted above is entirely driven by CWallet::CreateTransaction. I'm really not familiar with it and I suspect the interface isn't designed with bumpfee's use in mind.

At a minimum perhaps feebumper::CreateRateBumpTransaction should do its own logging?

No, it's not only log's issue! It's setting exact the same high fee rate when I'm setting confTarget=2 as for confTarget=0. It has different behavior at <=0.18.*

self.nodes[0].bumpfee(txid, {"confTarget":0})
*** test_framework.authproxy.JSONRPCException: Invalid conf_target, must be between 1 - 1008 (-8)

? 0 isn't an allowed request.

1 and 2 are aliases of each other, since we don't actually make estimates for 1 block.

Did another related test, bumping it twice from 30->5->1(same as 2), and all resulting mempool entries appear to be the exact correct feerate as per estimator values.

wrote some more comprehensive tests since we didn't have any https://github.com/bitcoin/bitcoin/pull/18245

@yurayakimenko is this still a problem for you?

@pinheadmz No, this problem was resolved. Thanks a lot!