Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Local transactions rejected due to low fee that work elsewhere #8679

Closed
andrewheadricke opened this issue May 22, 2018 · 12 comments
Closed

Local transactions rejected due to low fee that work elsewhere #8679

andrewheadricke opened this issue May 22, 2018 · 12 comments
Labels
F2-bug 🐞 The client fails to follow expected behavior. M4-core ⛓ Core client code / Rust. P2-asap 🌊 No need to stop dead in your tracks, however issue should be addressed as soon as possible.
Milestone

Comments

@andrewheadricke
Copy link

andrewheadricke commented May 22, 2018

I'm running:

  • Which Parity version?: 1.11.0
  • Which operating system?: Linux
  • How installed?: via binaries
  • Are you fully synchronized?: yes
  • Which network are you connected to?: ethereum
  • Did you try to restart the node?: yes

When submitting a transaction to the node, either via local wallet OR some externally signed tx it returns an error saying gas price is too low and tx queue is too long, therefore its dropped.

However my fee is always above the suggested average at ethgasstation, and when I send my tx via another provider it goes through immediately and is confirmed usually within 30-60 seconds.

There needs to be a way to forcefully allow local transactions over external ones.

@AdvancedStyle
Copy link

I'm having exact same issue after upgrading from v1.9.4 to 1.11.1:

There are too many transactions in the queue. Your transaction was dropped due to limit. Try increasing the fee.

Even if I increase the gas price to double the suggested gas price it still gives this error.

parity_localTransactions is showing rejected transactions with this error:

"error": "[0xd29a845c0f779b7e639d774e667b2253957bc312367cea481e7deaf80317644b] too cheap to enter the pool. Min score: 0x11e1a300"

This transaction has a gas price of 0x560de0700

@gituser
Copy link

gituser commented May 22, 2018

I'm having same issue, getting this response over RPC:

    'code' => -32010,
    'message' => 'There are too many transactions in the queue. Your transaction was dropped due to limit. Try increasing the fee.',

also, some transactions reported as mined, but in fact they were never included in the block and thus any new outgoing transactions are stuck because the nonce should be incremented from the last mined tx.

@tomusdrw
Copy link
Collaborator

Are all transactions originating from the same sender? Could you please try to increase --tx-queue-per-sender parameter to see if it helps with the issue?

Default value for this is 1% of the entire pool size, so a pool of 65k can support up to 600 transactions from a single sender.

There needs to be a way to forcefully allow local transactions over external ones.

I agree. We are investigating possible solutions.

@andrewheadricke
Copy link
Author

andrewheadricke commented May 23, 2018

@tomusdrw I don't believe they are all from the same sender.. my tx queue is showing 8192 transactions, with varying senders and gas prices.

I have just set --min-gas-price to 20 gwei, that has dropped my tx queue down to a more reasonable number. Not sure if Parity will allow me to submit a local tx with a lower gas price, my gut feeling is that it will. If so, that solution will do for now.

Edit: Wow, this guy is really spamming the network https://etherscan.io/address/0xceceaa8edc0830c7cec497e33bb3a3c28dd55a32

@gituser
Copy link

gituser commented May 23, 2018

@tomusdrw, in my case - most transactions are going from the same sender or to the same sender.
Also some are just stuck waiting to be mined, althrough log indicates that transaction has been mined.

But it doesn't matter, with v1.10.4 it works and with v1.9.7 it worked, why it should fail with v1.11.1 ?

I've also set --tx-queue-size to big number, I'll try your workaround, but I'm strongly believe this new parallel txqueue got a bug somewhere.

@andrewheadricke
Copy link
Author

Can confirm setting --min-gas-price works by reducing the tx queue to a point where its not full, and then was able to submit a tx below the --min-gas-price locally and Parity accepted it and relayed it.. to which it then got mined.

@gituser
Copy link

gituser commented May 23, 2018

@andrewheadricke I never submit any transactions with gasPrice below 20 Gwei. The node is only used by me so I can't see how this is relevant in my case.. I'll try though your suggestion. Thanks.

@Tbaut Tbaut added F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. P2-asap 🌊 No need to stop dead in your tracks, however issue should be addressed as soon as possible. M4-core ⛓ Core client code / Rust. labels May 23, 2018
@Tbaut Tbaut added this to the 1.12 milestone May 23, 2018
@tomusdrw
Copy link
Collaborator

@andrewheadricke I've submitted a fix for a local transaction policy in case the pool is full. Indeed local transactions should be accepted even if they are below configured min gas price.

@gituser Your issue seems a bit different if you are running with 65k pool size. I don't think it should ever be completely filled. Would you be able to provide logs for running with -ltxqueue=debug?

@tomusdrw tomusdrw added F2-bug 🐞 The client fails to follow expected behavior. and removed F3-annoyance 💩 The client behaves within expectations, however this “expected behaviour” itself is at issue. labels May 23, 2018
@AdvancedStyle
Copy link

@andrewheadricke I have just set --min-gas-price to 20 gwei

Do you know if it's possible to set this from the config file instead of passing as flag?

@tomusdrw
Copy link
Collaborator

tomusdrw commented May 24, 2018

@AdvancedStyle yes, it's:

[mining]
min_gas_price = 1 # 1 wei

@vn-linescode
Copy link

Did anyone solve?

@debris
Copy link
Collaborator

debris commented Jun 6, 2018

yes, it was solved in #8691 and it was released in 1.11.3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F2-bug 🐞 The client fails to follow expected behavior. M4-core ⛓ Core client code / Rust. P2-asap 🌊 No need to stop dead in your tracks, however issue should be addressed as soon as possible.
Projects
None yet
Development

No branches or pull requests

7 participants