availproject / avail

775 stars 529 forks source link

bug: Can't improve priority by adding tip to broadcasting transaction. #599

Closed foolstack-omg closed 1 month ago

foolstack-omg commented 1 month ago

Bug Report

Check the contributing guide

Description

I can't improve priority by adding tip to replace a tipped pending transaction.

Steps to Reproduce

  1. sending a transaction which tip is set to 100, and nonce is set to 1
  2. monitor the transaction being sent to the txpool with the pendingExtrinsics rpc function.
  3. set the new transaction' tip to 200, and nonce is set to 1
  4. Error return by the rpc: Priority is too low: (18446744073709551615 vs 18446744073709551615): The transaction has too low priority to replace another transaction already in the pool.
  5. if I set the tip to 0 at the first step, I can replace the transaction with a higher tip. In this situation, it works fine.

Expected Behavior

I can improve priority of the transaction in the tx pool by add more tip.

Actual Behavior

Actually, if one add 1 tip to a transaction, its priority is already set to 2^64 - 1, which is the maximum value of uint64.

Additional Information

rpc url: wss://turing-rpc.avail.so/ws npm package: avail-js-sdk

Leouarz commented 1 month ago

Hey, thank you for opening this issue, it's indeed an unwanted behaviour due to safe overflows.

In polkadot, the DOT has 12 decimals but the AVAIL has 18. The tip being of this type can overflow with that many decimals. Here's how the calculation will look like in comparison :

WITH AVAIL AND OUR 18 UNITS

max weight       =           2,000,000,000,000
weight           =              20,000,000,000
max tx per block =                         100
tip              =   1,000,000,000,000,000,001
scaled_tip       = 100,000,000,000,000,000,100 <-- OVERFLOW
max u64          =  18,446,744,073,709,551,615 <-- Will return this value

WITH POLKADOT AND THEIR 12 UNITS

max weight       =           2,000,000,000,000
weight           =              20,000,000,000
max tx per block =                         100
tip              =           1,000,000,000,001
scaled_tip       =         100,000,000,000,100 <-- Will return this value
max u64          =  18,446,744,073,709,551,615

Solution to this issue are in the corresponding PRs :

foolstack-omg commented 1 month ago

In the next version, how much tip I set to the transaction, will be the highest priority? 100,000,000,000,000,000,100?

Leouarz commented 1 month ago

Well you can put any tip you want it should be linear so you can even put 1M avail as tip and it will work as intended. Howere is there a particular reason to add tip ? It should be used only to override a tx or when the network is jammed which won't happen soon.

foolstack-omg commented 1 month ago

yes, I am using it to override a tx. Because my mnemonic is exposed. I would like to monitor the txpool so that I can override the tx if it exists.

Leouarz commented 1 month ago

The pull request has been merged, will be on the next update.