As far as I can tell from the Electrum source code there shouldn't be any difference between the mobile version and the desktop version since both are connecting to the same type of bitcoin nodes and both are getting their fee estimation from the same set of nodes. Only the UI and the platform are different.
That means if you are getting different fee estimations the nodes that you connect to are sending you different values.
Topic: Electrum Mobile wallet's inaccurate mempool estimations (Read 118 times)
Next time it happens, try to change server and then let Electrum run for a few minutes.
Because it heavily relies on the server since Electrum client itself doesn't have a mempool.
BTW, I'm using a specific server and the "unconfirmed transaction depth" is working, pretty accurate actually.
That's for v4.0.6 mobile (Android) and W10 PC.
Because it heavily relies on the server since Electrum client itself doesn't have a mempool.
BTW, I'm using a specific server and the "unconfirmed transaction depth" is working, pretty accurate actually.
That's for v4.0.6 mobile (Android) and W10 PC.
And that is by looking at the fees they pay. So they will prefer transactions paying more over less.
The question I was replying to was asking how miners would prioritize transactions if all transactions in the mempool were of the same fee rate. Further, they will not prioritize transaction paying more in fees, but rather transactions which pay a higher fee rate. They won't choose one transaction which pays 10,000 sats in fees if they could fit 5 transactions which each pay 5,000 sats in fees in the same space. 
Which factors are considered for a transaction to be of higher priority so as to be confirmed in the next block or be closer from the tip if all the transactions in the mempool were of the same free rate, say all were at 1 sat/byte at a given time?
There used to be a concept called transaction priority. It was based on the following formula:Code:
sum(input_value_in_base_units * input_age)/transaction_size_in_bytes
input_age was how many confirmations the input to the transaction had, so coins which had not been moved in a long time had priority over coins which were being moved around frequently. Transactions which moved larger quantities of bitcoin were higher priority, and transactions which were smaller in terms of bytes were higher priority.
This has all since been removed, though, and so is no longer relevant. Miners and pools will now decide for themselves which transactions to prioritize.
And that is by looking at the fees they pay. So they will prefer transactions paying more over less.
Which factors are considered for a transaction to be of higher priority so as to be confirmed in the next block or be closer from the tip if all the transactions in the mempool were of the same free rate, say all were at 1 sat/byte at a given time?
There used to be a concept called transaction priority. It was based on the following formula:Code:
sum(input_value_in_base_units * input_age)/transaction_size_in_bytes
input_age was how many confirmations the input to the transaction had, so coins which had not been moved in a long time had priority over coins which were being moved around frequently. Transactions which moved larger quantities of bitcoin were higher priority, and transactions which were smaller in terms of bytes were higher priority.
This has all since been removed, though, and so is no longer relevant. Miners and pools will now decide for themselves which transactions to prioritize.
>>>snip<<<
Ooh, I see now.
Which brings me to this question. Which factors are considered for a transaction to be of higher priority so as to be confirmed in the next block or be closer from the tip if all the transactions in the mempool were of the same free rate, say all were at 1 sat/byte at a given time?
I tried to make a transaction today but it looks fine to me with Electrum app 4.0.3.
Are you using the latest version of Electrum?
I am using 4.0.6. Not really the latest as a new version was released 2 days ago but transaction got confirmed a few minutes ago despite displaying that it was far away from the tip Are you using the latest version of Electrum?
I tried to make a transaction today but it looks fine to me with Electrum app 4.0.3.
Are you using the latest version of Electrum?
You might be using the latest version with some bugs or you might be using an older version than 4.0.3?
Try to clear the app cache on the phone settings then reopen the app again and check if there are changes.
Are you using the latest version of Electrum?
You might be using the latest version with some bugs or you might be using an older version than 4.0.3?
Try to clear the app cache on the phone settings then reopen the app again and check if there are changes.
I think the issue here is that the mempool currently looks like this:
The entire big blue section at the bottom is for transactions which are paying between 1 and 2 sats/vbyte. Therefore, a very small difference in the fee you pay would be enough to move your transaction from 0.01 MB from the tip to 13 MB from the tip. It would seem that Electrum's fee estimator has made a very small error here which has translated in to a huge change in mempool priority.
If I create a transaction on Electrum right now and use the "Mempool" slider for the fees, if I select 0.5 MB from the tip it gives me 2 sats/bytes, and if I select 10 MB from the tip it also gives me 2 sats/bytes.
The entire big blue section at the bottom is for transactions which are paying between 1 and 2 sats/vbyte. Therefore, a very small difference in the fee you pay would be enough to move your transaction from 0.01 MB from the tip to 13 MB from the tip. It would seem that Electrum's fee estimator has made a very small error here which has translated in to a huge change in mempool priority.
If I create a transaction on Electrum right now and use the "Mempool" slider for the fees, if I select 0.5 MB from the tip it gives me 2 sats/bytes, and if I select 10 MB from the tip it also gives me 2 sats/bytes.
when i tried to bump the fee, the app is still suggesting that a transaction of 2 sats/byte would be 0.5 MB from the tip
I don't think there is anything wrong here. It looks like 2 sat/byte was enough in the last three hours to get a transaction confirmed in the next block (source - look at the third graph). There was a small spike for a few minutes, but your transaction definitely was not over 13 MB from the tip.
Edit: Ah, now I can see your problem. I have just tried creating a watch-only wallet with some random address which has just sent a transaction. Someone paid over a 86 sat/byte fee and Electrum shows that the transaction is over 11 MB from the tip. There's clearly something wrong with Electrum.
I'm getting 8...
You're probably better off reporting this on their github: github.com/spesmilo/electrum/
(also find out who's running the server)
You're probably better off reporting this on their github: github.com/spesmilo/electrum/
(also find out who's running the server)
I was trying to send out a transaction a few moments ago through my electrum mobile wallet but was surprised by the outcome. First tjhe suggested fee was 2 sats/byte for a transaction that would be 0.5 MB form the tip but upon broadcasting the transaction, The app is now showing me something completely different. The transaction is now at 13.91 MB from the tip as suggested by the app 
when i tried to bump the fee, the app is still suggesting that a transaction of 2 sats/byte would be 0.5 MB from the tip
when i tried to bump the fee, the app is still suggesting that a transaction of 2 sats/byte would be 0.5 MB from the tip
Jump to: