Topic: How to pay less fees (Read 483 times)

Thank you all for your contributions.

@Muhammed Zakir:
Thank you for the link.
So when I interprete the diagram in the right way, during the last 24h, there was no chance that a transaction with <8 satochi/byte had been taken on this node.
According to this diagramm the recommendation of mocacinno to always add at least 15 satoshi's per byte seems to be a good advice.

Have you seen https://jochen-hoenicke.de/queue? Just mentioning as the visualization part is way better than bitcoinfees.


+10. I liked the way you described it.

One important thing to note when looking at sites like https://bitcoinfees.21.co/ and https://btc.com/stats/unconfirmed-tx is that they show the network status at this exact moment in time... and have no real way to predict what will happen in the next 10+ minutes/hours/days...

IMHO, those sites saying things like 1-30bytes for 4-25 block delay is misleading. It "could" be a 25 block delay assuming no further transactions with a higher fee are added into the mempool in the time it takes for 25 blocks to get confirmed... However, if a further 1 megabyte worth of transactions get added to the mempool after every block gets mined... and these transaction have even just a 10 sat/byte higher fee than yours... there is a good chance that your transaction would NEVER confirm.

A way to visualise this... imagine putting a sheet on paper down (your low fee transaction) and then putting 100 sheets of paper on top (everyone else's transaction with higher fees)... each block that gets mined removes say 10 sheets from the top... you can see that if 10 sheets get added into the pile above yours between blocks being mined... then the miners would forever just be taking the top 10 sheets and the pile would never shrink enough for yours to be picked up.

That's a fairly simplistic view of how the mempool works... but you should be able to get the idea...

You're actually asking questions about the technical part of bitcoin.


Bitcoin is a decentral ledger containing all confirmed transactions ever made. Each transaction is basically a bunch of scripts.
On one side of the transaction, you have the signed scripts used as an input of the transaction. The input scripts are signed with the private key belonging to the public key, belonging to the address that was used to send BTC to (to keep it simple.. In reality i'm skipping a couple of things).
On the other side of the transaction, you have scripts stipulating who can spend the output of the transaction. You basically say: the person who can provide a valid signature that can be verified using the public key from witch address [address] was derived can use this output as an input to create a new transaction.

After you generate this transaction, you broadcast it to the network. If the transaction is valid (the signatures are ok, the inputs are not yet used in a different transaction,...) it is accepted in the mempool of the nodes you broadcasted the transaction to. These nodes will broadcast your transaction to the nodes they are connected to, and so on, untill the full network knows about your unconfirmed transaction.


As long as your transaction remains in the mempool of a single mining node, it has a chance of being added to the block that particular miner is currently solving. If the miner finds a block below the target diff, and he's able to push the block to the network fast enough (so it becomes part of the main chain) your transaction is confirmed.

There is no 2-hour limit. As long as your transaction is floating around in mempools, it has a chance of being confirmed...

Thank you for this.

In general: Am I right that the nature of sending bitcoins is something like a stub of a balance. Either my sent bitcoins arrive at the new adress within 2-3 hours or the never will arrive at this adress.

No prob.

BTW, i just realised i forgot to tell you about 2 sollutions for low fees that ARE implemented in electrum
1) if you are the receiver OR if you sent change to your change address, and the transaction becomes stuck => right click => child pays for parent (cpfp) (i don't have a stuck transaction right now, so i can't verify the exact wording).

2) if you send transactions, make sure they're always marked as replaceable... You can even go to your preferences and make sure every transaction you create is opt-in RBF (replaceable). If an opt-in RBF transaction gets stuck, electrum will provide a nice wizard to create a new transaction using the same inputs. In theory, this is double spending the inputs, but since your transaction was opt-in RBF, it's much cleaner, and the double spending transaction will (hopefully) have a much lower rejection rate compared to a "real" double spending transaction.

Thank you for the link. I will go into that book.

Thank you for your kind help.

No, it's not implemented in electrum
https://www.viabtc.com/tools/txaccelerator/

Read their service agreement and TA before panicking, they have a set of rules about when and how many transactions they accept!

Are this tricks implemented in Electrum? If yes how can I apply them?

Theoretically, yes, 1 sat/byte *should* be sufficient... However, if somebody decides to dump a couple thousand transactions with a higher fee into the network, you would be screwed... Also, there are nodes out there that reject transactions that don't have a minimum fee. I'm pretty sure a 226 satoshi fee transaction wouldn't propagate trough the full network.

It's all odds and averages... If everything would remain status quo, you'd have a 95% chance of getting into the next 28 blocks (so ~360 minutes), but the longer you're willing to wait, the bigger the odds that the status-quo will be disturbed, and the average fee goes up before your transaction ends up in a block.

I would recommend to always add at least 15 satoshi's per byte, since there are a couple of tricks you can use to accelerate a transaction if it has at least 10 satoshi's per byte.

At the moment it is 1-30 Satoshi/Byte for a 4-28 block delay. So when I have a transaction which is 226 bytes and I chose 1 Satoshi x 226 = 226 Satoshi, this is a price which will not run into any problem at the moment?


Thank you. Good news.

No, i don't think it's a good idear to just halve the fee suggested by electrum... You really should calculate the fee you want to add manually by looking up how long you're prepared to wait (on average) by visiting a site like https://bitcoinfees.21.co/.

BTC's can't be lost forever. A transaction gets generated and broadcasted. When it's received by the nodes, they put the data into their mempool. This mempool is full of unconfirmed transactions using outputs that are available in their UTXO set (the database with unspent outputs that can be used to create a transaction).

After ~3 days, most nodes kick the unconfirmed transactions from their mempool. So, in theory, you can re-use the unspent output to create a new transaction after 4 or 5 days. This way, your new transaction will use the same input as your previous transaction, so you're actually creating a double spent. This double spending transaction will be rejected by the nodes that still have the previous transaction in their mempool (since your new transaction uses the same input), but it will be accepted by the ones that already dropped the previous transaction.
So, in the end, the double spending transaction will have less network propagation, but usually they propage sufficiently to reach the mempool of at least some mining nodes...

Thank you.

Can it be a good idea, just to chose the half fees which Electrum suggests in the 25 block mode?

Or can this already lead to insufficient network propagation, unconfirmed transactions getting dropped from the mempool,... ? (As you wrote)

Can Btc's be lost for ever, when I chose a fee that is too little? So is this a risk?

Not ~really~... It's all about odds and averages. The network difficulty gets adjusted every 2016 blocks. The adjustment's purpose it to make sure the average time between two blocks is ~10minutes with the current network hashrate.
Since it's 10 minutes on average, the real time might be from 0 to infinity minutes, but on average it should be around 250 minutes IF the estimation of the fee was correct. In reality it will most likely be less or more.

preferences => edit fees manually
now generate a transaction, click on preview, look at the size. This is the size of the UNSIGNED transaction, so the signed transaction will probably be a bit larger.
Go to https://bitcoinfees.21.co/, look up which fee you want to use, multiply with the estimated size of the signed transaction, and set this fee manually.
I do not recommand using very low fees, it leads to insufficient network propagation, unconfirmed transactions getting dropped from the mempool,...

We can adjust our fees, depending how fast the transfer should be done.

1. Question:
Am I right: If I chose 25 blocks (it's the minimum fee) it will take 25x10 minutes = 250 minutes  until the bitcoins appear in the new adress?

2. Question:
250 minutes is still very fast. I have no problem to wait one day or more and pay less fees.
But as far as I can see: 25 blocks are the minimum. What can I do, if I want to get the fee for 300 blocks? How can I send Btc for less fees than I have to pay for 25 blocks?

Thank you for an answer.