I'm working on a project that takes BTC from address A and sends it to address B. The idea is to clear out address A as much as possible, ideally leaving it empty. And just to clarify, I'm not creating any malware, so no need to panic.
Using python with the bitcoinlib package here.
I'm trying to figure out the right amount of BTC to send in a transaction and how much I need to allocate for the transaction fee.
From what I gather, when BTC goes to address B, it doesn't actually show as being there. Instead, it’s the inputs from address A that show up in address B. It's like adding a $20 bill to a wallet that already has $80. You don't blend it all into a $100 bill; you just keep the bills separate (like a $20, a $50, and a $10).
So, let’s break it down:
We've got address D, which is empty (no inputs or outputs).
Address A sends 1 BTC to address D.
Address B sends 2 BTC to address D.
Address C sends 0.5 BTC to address D.
So technically, address D doesn’t have 3.5 BTC; it has 1 BTC from A, 2 BTC from B, and 0.5 BTC from C. That's three different inputs into address D. I know it sounds a bit wonky, but am I on the right track?
Now, if I want to send around 1 BTC (1 BTC minus the transaction fee) from address D to another address, do I get to pick which inputs to use from D, or does the blockchain decide that? If it's my choice, would using the input from Address A be the best option since it’s just one input?
Yes.
You can choose any of your inputs. Some wallets can do that for you, but from the protocol perspective, any user can pick any coins, and also decide about their order.
It depends on the final transaction size in virtual bytes. You can prepare your transaction with zero fees, sign it, and then check, how many virtual bytes it takes, and then decrease output amounts however you want, to make transaction fee out of that.
User can pick any inputs in any order, and user can also make any outputs, with any amounts, in any order, and with any address types. From the protocol level, user can make any transaction. As long as it is valid, it will be accepted. Which means, that you can send all coins to one address, as a single coin, but you can also split it between many smaller coins. Even if splitting is unnecessary, as long as transaction is valid, it will work.
Is that what you wanted to achieve? All inputs of a given transaction are used to make all outputs of a given transaction. As long as things are signed with SIGHASH_ALL, everything is signed by each and every input. Which means, that you have just the sum of all inputs (0.25+0.50=0.75), and the sum of all outputs (0.40+0.10=0.50), and then the difference between them (0.75-0.50=0.25) is the transaction fee. Which means, that 0.40 BTC from Elaine does not come only from 0.25 BTC held by Daniel, or only from 0.50 BTC held by Charlie. It comes from both, unless you have signatures other than SIGHASH_ALL. And the same with Dave.
So, by default, you have all inputs, which are used to make all outputs, and nobody knows, which input was used to make which output. Of course, people can try to guess it, by looking at amounts, and judging, that if everyone transferred 0.01 BTC input to 0.009 BTC output, and one 1 BTC input was moved into one 0.999 BTC output, then they are likely to be connected, but from the protocol perspective, all inputs made all outputs, even if humans can guess it right, who sent what to whom.
1. You prepare everything with zero fees.
2. You sign it with zero fees, and check, what is the size of your transaction.
3. You adjust output amounts, however you like.
4. Changing coin amounts does not affect transaction size, so it will have the same feerate.
5. You sign the final version, with non-zero fees, and broadcast it to the network.
When you talk about the inputs of a transaction from the perspective you mentioned, the correct way to refer to it would be UTXO.
You can filter these UTXOs by address, which would be the most convenient in your case, however, you could filter them by amount or by age.
Regarding Python, You can use a Bitcoin node to interact with Bitcoinlib or an external API to create transactions at your own convenience.
also you could use an API to automate the estimation of the current fee(taking into account that these APIs have certain limits in their free versions), like:
and then apply that data to the weight of your transaction to calculate the fees.
But I recommend taking a look at the BitcoinLib documentation, as this topic is sensitive and you could end up losing funds if you make a mistake.
This is only valid if the number of inputs and outputs does not change, if the new amount requires more UTXOs to complete the amount sent, the transaction will increase in size, which will affect the fees.
You can't try to calculate the fee by itself without using an API because there is to native calculation for you to do for obtaining the fees unless you use an API or the Bitcoin Core RPC functions.
Fees are set by the current size of the mempool but there isn't an exact estimation that you can perform unless you gathered all the transactions and calculated the fee that they are paying.