Absurd high fee rate for a Funded Send All transaction

[efpies]

Here's a “Send All” transaction that was created by omni_funded_sendall.

https://blockchair.com/bitcoin/transaction/4310934654fedc2b2a3e5c9949cf3efd4065bc1bec7c4517402ef36b364dec58

That's a whopping 530 satoshis/byte.

This is the config:

  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,

Average tx fee is significantly lower:

Excuse me, but wth? How is that possible?

[dexX7]

Hello @efpies,

there is another setting, which is highly relevant here: the -txconfirmtarget.

[fomo8]

Hi @dexX7 , We have set -txconfirmtarget to 6, still we got sendall txs paying >1,000 sat/B fees.

An example: https://www.blockchain.com/btc/tx/67aaa681fe5b87b0978cb42a559b96f2163e110ab143e7ed094cb1d3522f6dea

this never happen for simple send txs. Is there any other setting that could help us limit the maximum txfee per tx?

Thanks!

[letreset]

@dexX7 we have same problem. We are seeing this situation sendall tx's. https://www.blockchain.com/btc/tx/6f1cfeaadd033fb179b82131886d80a56e98a1f8963cf4fb1d313202da4f4c08

[du2zy]

The same problem happens with the omni_funded_send method, but never with omni_send. Sometimes fee exceeds 0.02 BTC for transaction.

@dexX7, can you reopen this issue?

[du2zy]

@efpies @fomo8 @letreset Did you find the cause of this problem? Do you know steps to reproduce the problem? In my case, the problem arises absolutely arbitrarily, and I don't know how to debug it.

[efpies]

@du2zy Same, no steps to reproduce. Normal omni_send txs have normal fees, so I don't see how playing with -txconfirmtarget would help. Maybe it implies that omni_funded_sendall uses it and omni_send doesn't. Maybe fees fluctuate like crazy, so 2 consequental tx have fees that are 7 times different from each other.

The tx in my question is literally the most expensive in the whole block. https://blockchair.com/bitcoin/transactions?q=block_id(554939)&s=fee_per_kb(desc)#

[du2zy]

@efpies

In my case, when using omni_funded_send, some transactions cost big money, some - as usual. I can not understand what it depends on. I have a few ideas, but I’m not ready to test with real money, but I’m not able to catch the problem in testnet.

How did you solve this problem? Ready to pay a high commission if you need to use a funded send?

[efpies]

Yes, we're ready to pay a commission since we don't want to make the tx manually. But we may opt to calculate fees manually based on the mempool state and previous blocks. Maybe it won't be based on fancy formulae, but it will be times cheaper.

[dexX7]

Hey guys,

we noticed that some funded transactions had absurd high fees and dig deeper: in these cases the address had a lot of unspent outputs, which created a more and more expensive transaction during the coin selection.

Does this somehow apply to your cases as well?

[dexX7]

Looks like this is the case for 1K5M6LqWhLbpse74TezgnWuUx2g4oDhuEc and 1Jkvb8QxUb5EyBpoPaC5rfGTHfG6uYNiQE.

We have a fix for this in the work.

[atlaspio]

Looks like this is the case for 1K5M6LqWhLbpse74TezgnWuUx2g4oDhuEc and 1Jkvb8QxUb5EyBpoPaC5rfGTHfG6uYNiQE.

We have a fix for this in the work.

Hey @dexX7 ,

Thanks for picking this up, if it is any help, I can provide some more detail about 1Jkvb8QxUb5EyBpoPaC5rfGTHfG6uYNiQE:

We have a product that allow our users to deposit USDT to our system for later commercial activities. We used omni_funded_sendall to move all the deposits, and 1Jkvb8QxUb5EyBpoPaC5rfGTHfG6uYNiQE was the account we used at that time to pay for the fees. We used -txconfirmtarget and set it to 6 The from accounts involved in those transactions are new accounts that has no prior activity, except being sent some USDTs.

One thing worth mentioning that most of our users are sending USDTs our way through a crypto exchange withdraw, which involve some highly active accounts.

[thisdaydayde]

Looks like this is the case for 1K5M6LqWhLbpse74TezgnWuUx2g4oDhuEc and 1Jkvb8QxUb5EyBpoPaC5rfGTHfG6uYNiQE.

We have a fix for this in the work.

sir，may I ask have you fixed it?