0

This is a follow-up post to this question.

I am using Electrum to send Bitcoin. From what I can gather, it doesn't seem like there is a way to know your "inputs" upfront. The inputs are the various addresses the different chunks of bitcoin are coming from... I think? So the inputs, as I understand, will depend on the source.

I am trying to figure out the best way to calculate the fee I can charge the client for the transaction. So my questions are:

  1. Is there any way that I can assume 1 input for my calculations? Or find another way to get a more accurate fee calculation?
  2. I can't have a fixed fee of, for example, 0.0005, because that will probably work fine for small amounts, but if someone sends a large amount, the fee could easily be more than this. Is there a way to know what the worst case cost could be for sending 0.01 BTC versus sending 20 000 BTC?
  3. Is there a maximum or "worst-case" formula I could use to work out what the absolute highest a fee could be for a specific scenario?
2

From what I can gather, it doesn't seem like there is a way to know your "inputs" upfront. The inputs are the various addresses the different chunks of bitcoin are coming from... I think? So the inputs, as I understand, will depend on the source.

Your wallet's balance is comprised of the various 'unspent transaction outputs' (UTXOs) it controls. These UTXOs can be used as inputs for new transactions (which will create new UTXOs). Some software will allow you to manually manage your UTXOs ('coin control'), which means you can pick specific UTXOs to be used as inputs for a new transaction.

This page appears to have a walkthrough of the process when using electrum: https://bitcoinelectrum.com/how-to-spend-specific-utxos-in-electrum/ (disclaimer: I am not affiliated with that site and have not verified its legitimacy, but at a very quick glance it appears it may be helpful to you).

Is there any way that I can assume 1 input for my calculations? Or find another way to get a more accurate fee calculation?

Assuming 1-input for all your transactions will probably not work well in real life. Any transactions you send that have multiple inputs will end up with fees that are lower than intended, which will likely result in long confirmation times (or, a transaction that never confirms).

The most accurate method is to simply first determine the size of the transaction you are sending (vbytes), as well as the fee-rate you would like to send it with (sats/vbyte), and then multiply the two numbers to determine the total fee (sats).

I can't have a fixed fee of, for example, 0.0005, because that will probably work fine for small amounts, but if someone sends a large amount, the fee could easily be more than this.

This is a misunderstanding of how fees work, it does not matter what the value being sent is, only the number of bytes for the transaction.

But otherwise, in general a fixed fee is not a good solution at all.

Is there a way to know what the worst case cost could be for sending 0.01 BTC versus sending 20,000 BTC? Is there a maximum or "worst-case" formula I could use to work out what the absolute highest a fee could be for a specific scenario?

You can set the fee-rate as high as you'd like. 'Worst case' would be sending 100% of the transaction value to miner fees.

|improve this answer|||||
  • "The most accurate method is to simply first determine the size of the transaction" - How would you do this though? Because that is what I want to do. Is get the actual cost. Not an estimate. But I don't know how I would calculate the size? – coderama Dec 9 '19 at 17:37
  • 1
    @coderama choose the appropriate inputs from what you have available, create outputs, and then determine the size of the resulting transaction. The electrum software is quite capable of doing this. – chytrik Dec 9 '19 at 21:01
  • Thanks! Problem is I'm not using the GUI. I am using the command line. But thanks! That will steer me on the right path I'm sure! – coderama Dec 9 '19 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.