Topic: Does reusing addresses lower fees? (Read 223 times)

The public key of the compressed will be smaller, 33 bytes and 65 bytes respectively. Bitcoin Core implemented this change really long ago, 4 or 5 years ago, IIRC. Your client probably has the compressed generated for you, WIF for compressed address starts with K and L while the uncompressed starts with K.

Uncompressed. The private key of the two keys would remain the same, compressed or uncompressed. However, the public key would be different and after the encoding process, it would result in an entirely different address. The prefix of the WIP would tell the wallet what kind of key it is and the wallet would generate it accordingly.

I have my cold storage on legacy addresses, due the "anyone can spend" exploit possibility of funds being stolen. Call me crazy paranoid if you want.

No

No it will not lower your fees because the only thing that matters really is that the fee is based on the transaction size in terms of bytes.

I also want to add that you should switch to SegWit (either native or P2SH nested) if you want to save on fees. Their transaction sizes have a lower weight then legacy transactions (compress/uncompressed), giving them a smaller virtual transaction size. A SegWit transaction with 1 input and 2 outputs has a virtual size of 140 bytes, which is significantly lower than transacting with legacy. SegWit is also a lot smaller if you have a large number of inputs. For instance, I just made this SegWit transaction, which has 39 inputs and 1 output (I was consolidating my inputs). That transaction has a virtual size of 2538 bytes, compared to 5816 bytes if I was using compressed addresses, or 7064 bytes if I was using uncompressed. I'm using P2WPKH (nested SegWit addresses) as there's better support for them, but I believe bech32 (native) is even smaller than P2WPKH.

Yes... BUT, only if addresses A, B, C and E were all compressed or uncompressed. If some are compressed and others are uncompressed, then the sizes will be different (not by much, by they will be different).


Number of inputs AND number of outputs (but to a lesser extent as they're smaller) affect the data size of a transaction. You are correct that the "value" of BTC has NO affect on the "data" size of the transaction though... so a transaction for $1,000,000.00 could theoretically be "smaller" than a transaction for $10.00


The simple formula for compressed addresses is this:
Transaction size = (Number of Inputs * 148 bytes) + (Number of Outputs * 34 bytes) + 10 bytes


The simple formula for (older) uncompressed addresses is this:
Transaction size = (Number of Inputs * 180 bytes) + (Number of Outputs * 34 bytes) + 10 bytes


These formulas, will generally calculate the transaction size within an error margin of a few bytes as long as the number of inputs is less than 10 It's basically an +/- margin of about 2 bytes per input. They are also only valid for transactions from "1"-type addresses.

So, in the end, it comes down to some pretty simple maths... work out how many inputs you have, in your example we have 3... and how many outputs... again, using your example we have 1. Let's pretend your wallet is using compressed addresses (most newer wallets tend to use compressed addresses)... so now, we can see:

Transaction Size = (3 * 148) + (1 * 34) + 10
=> 444 + 34 + 10
=> 488 bytes

It might be maybe 6 bytes off... but should be valid for "estimating" a good fee... bitcoinfees.earn.com is saying that "recommended" is 410 sats/byte for "next block" confirmation...

So, 488 * 410 = 200,080 sats => 0.00200080 BTC for a fee... which is about USD$37... I hope you're transacting $1mil and not $10

I grabbed this quote from another thread which also link to bitcoin.stackexchange
He's trying to show this: 3*180 + 1*34 + 10 +- 3 = 584  +- 3
as you can see his actual tx size is "Size 583 (bytes)"

Yes, exactly!

Yes, amount being transacted doesn't matter now. It used to for tx prioritize, but no longer.

So if I understood correctly, it's like I said, the same thing.

A = 0.01         tx1
B = 0.02         ----->     D = 0.032
C =  0.002




E = 0.01        tx2
E = 0.02        ----->      F = 0.032
E = 0.002


In transaction 1, you received a total 0.032 in 3 different addresses, then you sent it to address D.

In transaction 2, you received the same amount of BTC in 3 different transactions of the same amounts to the same address (E), then you sent it to address F.

Transaction size of tx1 and tx2 are the same, is this correct?

Also, would this be correct irrespective of the amounts being sent because what matters is the number of inputs on a transaction?

I still don't quite get how size and therefore fees are calculated, and I don't get what you tried to show me there with your blockchain link to be honest.

No.

The fee is based on the transaction size (in bytes). Two inputs from two different addresses are the same size as two inputs from the same size.
Check my transaction: 3 inputs from the same (uncompressed) address produces a 583 bytes transaction.

Example, you use a certain address to receive payments which are pretty small (example, a signature campaign). In order to improve your privacy, you use a different address to receive the payments each time, or at least on every different campaign you participate in. This would leave you with different small amounts sitting on different addresses.

Say I get 0.01 in A, 0.02 in B, 0.002 in C.

I want to send the total of A+B+C so I select these with Coin Control in Core for a total of 0.032 BTC

If instead of using 3 different addreses, I used the same address A for the 3 different payments (so A=0.032), would this "A to some other address" transaction cost less fees? or the fees would be exactly the same because it would still count as 3 transactions within A? I hope this makes sense.