Bitcoin Forum
June 14, 2024, 05:29:39 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: "Replace-by-Fee": How to increase fee from Electrum?  (Read 238 times)
pxstein (OP)
Newbie
*
Offline Offline

Activity: 24
Merit: 22


View Profile
June 04, 2018, 03:26:05 AM
 #1

When I send BTCs to another address the "Replace-by-fee" flag is automatically set.
Thats fine.

Question in advance:
Is there a way to let me estimate how long the currently pending transaction will most probably need to be executed?
I can imagine that there is a webpages which shows this information.

Now lets assume the time is much too long and I want to replace the previously offered fee by a higher fee.

How do I achieve this in detail?

Should I simply re-enter and re-send the previous transcation this time with a higher fee?
Or do I need a transaction reference number?
Or do I have to set somewhere a flag "This is a replace-fee transaction"?

Most important: How does the Mining pool identify the replacement?
Its not that simple as it seems to be at a first glance.

Assume the original transaction looks like (addresses are shortened for simplicity):

send 0.001 BTC from 665577 to 123456 with 0.0000002 BTC offered fee

Now when I re-enter in "send" tab the same target address then Electrum  could automatically select another senders address.
The user has hardly any chance to enter the original senders address since Electrum AUTOMATICALLY select it.
Now let say Electrum randomly selects as senders address this time 442211 and generates the following transaction

send 0.001 BTC from 44221 to 123456 with 0.00005 BTC offered fee

How does the mining pool know that this is a fee replacement transaction?

Thank you
Peter



Ayanamirs
Member
**
Offline Offline

Activity: 137
Merit: 10


View Profile
June 04, 2018, 04:16:38 AM
 #2

All you need to know.


https://coinb.in/#fees

https://bitcoinelectrum.com/frequently-asked-questions/#my-bitcoin-transaction-is-not-confirming-what-can-i-do

https://bitcoincore.org/en/faq/optin_rbf/
pooya87
Legendary
*
Offline Offline

Activity: 3486
Merit: 10641



View Profile
June 04, 2018, 04:22:01 AM
 #3

Is there a way to let me estimate how long the currently pending transaction will most probably need to be executed?
I can imagine that there is a webpages which shows this information.
https://bitcoinfees.earn.com/
but be warned that this site is known to give higher fee suggestion than normal most of the times. for example currently it is suggesting 10 s/b now while paying 2-3 s/b is more than enough.

basically the estimation is based on how much others are paying in the mempool this is a much better link: https://jochen-hoenicke.de/queue/#0,24h but you have to understand the charts.       

Quote
Now lets assume the time is much too long and I want to replace the previously offered fee by a higher fee.

How do I achieve this in detail?

Should I simply re-enter and re-send the previous transcation this time with a higher fee?
Or do I need a transaction reference number?
Or do I have to set somewhere a flag "This is a replace-fee transaction"?

Most important: How does the Mining pool identify the replacement?
Its not that simple as it seems to be at a first glance.

for you as a user it is simple. you go to your history tab, if the tx is still unconfirmed you will see a different icon on its left side. and when you right click it there will be an option to "increase fee" you simply select it and a set a higher fee for your transaction and confirm it. you are done.

what happens under the hood is that your transaction already has the RBF flag so the mining pools that have this feature enabled will see it and will look for possible new replacement transactions. if you make a new one they will simply drop the previous one from their mempool and put the new one in it.
what your wallet does is that it simply take an extra amount from your change output and puts it in fee (basically you pay a smaller amount to your change so it  automatically goes to fee). you are in fact creating a new transaction but with the same keys and different amount.
something like this:


after bumping fee:

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
NeuroticFish
Legendary
*
Offline Offline

Activity: 3710
Merit: 6420


Looking for campaign manager? Contact icopress!


View Profile
June 04, 2018, 05:26:33 AM
 #4

https://bitcoinfees.earn.com/
but be warned that this site is known to give higher fee suggestion than normal most of the times. for example currently it is suggesting 10 s/b now while paying 2-3 s/b is more than enough.

basically the estimation is based on how much others are paying in the mempool this is a much better link: https://jochen-hoenicke.de/queue/#0,24h but you have to understand the charts.       

I use https://btc.com/stats/unconfirmed-tx
I find it much simpler and usually it's enough info. Just this one sometimes suggests a bit lower fee than I'd advise, especially if the transaction is non-SegWit.

█████████████████████████
████▐██▄█████████████████
████▐██████▄▄▄███████████
████▐████▄█████▄▄████████
████▐█████▀▀▀▀▀███▄██████
████▐███▀████████████████
████▐█████████▄█████▌████
████▐██▌█████▀██████▌████
████▐██████████▀████▌████
█████▀███▄█████▄███▀█████
███████▀█████████▀███████
██████████▀███▀██████████
█████████████████████████
.
BC.GAME
▄▄░░░▄▀▀▄████████
▄▄▄
██████████████
█████░░▄▄▄▄████████
▄▄▄▄▄▄▄▄▄██▄██████▄▄▄▄████
▄███▄█▄▄██████████▄████▄████
███████████████████████████▀███
▀████▄██▄██▄░░░░▄████████████
▀▀▀█████▄▄▄███████████▀██
███████████████████▀██
███████████████████▄██
▄███████████████████▄██
█████████████████████▀██
██████████████████████▄
.
..CASINO....SPORTS....RACING..
pooya87
Legendary
*
Offline Offline

Activity: 3486
Merit: 10641



View Profile
June 05, 2018, 03:18:04 AM
 #5

I use https://btc.com/stats/unconfirmed-tx
I find it much simpler and usually it's enough info. Just this one sometimes suggests a bit lower fee than I'd advise, especially if the transaction is non-SegWit.

that sites seems to be so much better than the earn.com site. but i still prefer my mempool analysis way of determining the best fee. basically you are better off letting Electrum decide, you can also set it on mempool fee estimation


the way it works is that you basically look at the following chart and decide which fee falls in less than block size which is about 1.2 MB on average these days but i usually choose 1 MB to be safer and to be a round number.
https://jochen-hoenicke.de/queue/#1,2d


.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
HCP
Legendary
*
Offline Offline

Activity: 2086
Merit: 4316

<insert witty quote here>


View Profile
June 10, 2018, 02:59:13 AM
 #6

It's worth noting that "Less than 1 MB" will only be "100% confirmed in the next block" if the block is found at that instant.

In that example shown above, if you were to use a fee of 3 sats/byte (0.998 MB)... and no miners found a block for another hour... and 10,000 more transactions were broadcast in that time, all using a fee of 5+ sats/byte, it is highly likely that your 3 sats/byte transaction would get bumped over the "1meg" block size and could miss out on "next block" confirmation.

If you REALLY want/need to guarantee "next block", it is probably safer to aim for around the 75-80% mark of "1meg"... and use that. In the example shown, you'd want to try using 5 or 6 sats/byte. Unless the transaction is absolutely huge, you're only looking at a difference of probably around 500-1000 sats in terms of the fee but significantly increasing the odds of getting in the next block.

█████████████████████████
████▐██▄█████████████████
████▐██████▄▄▄███████████
████▐████▄█████▄▄████████
████▐█████▀▀▀▀▀███▄██████
████▐███▀████████████████
████▐█████████▄█████▌████
████▐██▌█████▀██████▌████
████▐██████████▀████▌████
█████▀███▄█████▄███▀█████
███████▀█████████▀███████
██████████▀███▀██████████
█████████████████████████
.
BC.GAME
▄▄░░░▄▀▀▄████████
▄▄▄
██████████████
█████░░▄▄▄▄████████
▄▄▄▄▄▄▄▄▄██▄██████▄▄▄▄████
▄███▄█▄▄██████████▄████▄████
███████████████████████████▀███
▀████▄██▄██▄░░░░▄████████████
▀▀▀█████▄▄▄███████████▀██
███████████████████▀██
███████████████████▄██
▄███████████████████▄██
█████████████████████▀██
██████████████████████▄
.
..CASINO....SPORTS....RACING..
█░░░░░░█░░░░░░█
▀███▀░░▀███▀░░▀███▀
▀░▀░░░░▀░▀░░░░▀░▀
░░░░░░░░░░░░
▀██████████
░░░░░███░░░░
░░█░░░███▄█░░░
░░██▌░░███░▀░░██▌
░█░██░░███░░░█░██
░█▀▀▀█▌░███░░█▀▀▀█▌
▄█▄░░░██▄███▄█▄░░▄██▄
▄███▄
░░░░▀██▄▀


▄▄████▄▄
▄███▀▀███▄
██████████
▀███▄░▄██▀
▄▄████▄▄░▀█▀▄██▀▄▄████▄▄
▄███▀▀▀████▄▄██▀▄███▀▀███▄
███████▄▄▀▀████▄▄▀▀███████
▀███▄▄███▀░░░▀▀████▄▄▄███▀
▀▀████▀▀████████▀▀████▀▀
pooya87
Legendary
*
Offline Offline

Activity: 3486
Merit: 10641



View Profile
June 10, 2018, 10:50:39 AM
 #7

It's worth noting that "Less than 1 MB" will only be "100% confirmed in the next block" if the block is found at that instant.

In that example shown above, if you were to use a fee of 3 sats/byte (0.998 MB)... and no miners found a block for another hour... and 10,000 more transactions were broadcast in that time, all using a fee of 5+ sats/byte, it is highly likely that your 3 sats/byte transaction would get bumped over the "1meg" block size and could miss out on "next block" confirmation.

If you REALLY want/need to guarantee "next block", it is probably safer to aim for around the 75-80% mark of "1meg"... and use that. In the example shown, you'd want to try using 5 or 6 sats/byte. Unless the transaction is absolutely huge, you're only looking at a difference of probably around 500-1000 sats in terms of the fee but significantly increasing the odds of getting in the next block.

a very good point but i would argue that there still exists a better solution and the first thing should not be the "pay higher fee" that we run to.
the better solution is using RBF and keeping an eye on things. here is the scenario.
you find the best fee, lets say it is 3 s/b and send the transaction as RBF. in majority of cases it will be enough and you will get a fast confirmation in next block.
in rare cases where:
- there is no block found for an hour or more
- the next block(s) found are empty or miners are intentionally ignoring your tx
- a new block is found fast (eg in next 10 minutes) but right after you sent your transaction a spam attack starts and fills the mempool with 4 s/b transactions.
by keeping an eye on things you simply bump the fee to 5 s/b and have your tx confirmed fast still.

now the difference is that the chance of second scenario happening is small enough to be worth the effort and the time is not that long. it usually is 10 minutes or so. in other words from 100 tx that you send you may be forced to bump the fee for only 1 or 2 of them.

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!