Bitcoin Forum
October 16, 2018, 03:39:25 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Does reusing addresses lower fees?  (Read 92 times)
cellard
Legendary
*
Offline Offline

Activity: 1162
Merit: 1150


View Profile
December 17, 2017, 05:49:10 PM
 #1

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.

1539704365
Hero Member
*
Offline Offline

Posts: 1539704365

View Profile Personal Message (Offline)

Ignore
1539704365
Reply with quote  #2

1539704365
Report to moderator
1539704365
Hero Member
*
Offline Offline

Posts: 1539704365

View Profile Personal Message (Offline)

Ignore
1539704365
Reply with quote  #2

1539704365
Report to moderator
1539704365
Hero Member
*
Offline Offline

Posts: 1539704365

View Profile Personal Message (Offline)

Ignore
1539704365
Reply with quote  #2

1539704365
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1539704365
Hero Member
*
Offline Offline

Posts: 1539704365

View Profile Personal Message (Offline)

Ignore
1539704365
Reply with quote  #2

1539704365
Report to moderator
LoyceV
Legendary
*
Offline Offline

Activity: 1274
Merit: 2105


Self-made Legendary!


View Profile WWW
December 17, 2017, 05:58:30 PM
 #2

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?
No.

Quote
or the fees would be exactly the same because it would still count as 3 transactions within A?
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.

cellard
Legendary
*
Offline Offline

Activity: 1162
Merit: 1150


View Profile
December 18, 2017, 12:39:59 AM
 #3

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?
No.

Quote
or the fees would be exactly the same because it would still count as 3 transactions within A?
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.

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.

Thirdspace
Hero Member
*****
Online Online

Activity: 770
Merit: 598


Mixing reinvented for your privacy | chipmixer.com


View Profile
December 18, 2017, 03:48:40 AM
 #4

I grabbed this quote from another thread which also link to bitcoin.stackexchange
So if your transaction has in inputs and out outputs, the transaction size, in bytes will be:
in*180 + out*34 + 10 plus or minus 'in'

For example, this transaction has 40 inputs and 16 outputs. That gives us a transaction size of
40*180 + 16*34 + 10 +- 40
i.e. 7754 +- 40 bytes. The actual size is 7761 bytes.

If the inputs are from "pay to pubkey" transactions then the inputs are smaller than for "pay to address" transactions. And this will be different also for "pay to script hash" inputs too, depending on how/if that's implemented.

Edit2: Now that compressed public keys are commonplace, each input is 32 bytes shorter and so the transaction size is now:
in*148 + out*34 + 10 plus or minus 'in'
whether all inputs from the same address or multiple address doesn't make any different
what matter is the input address whether compressed or uncompressed,
each unspent from compressed address will contribute 148 bytes while uncompressed 180 bytes
whatever the destination/output address (compressed or uncompressed) will add 34 bytes per output
miners will pick the txs included in a block based in the order of highest to lowest rate tx fee queued in the mempool

Check my transaction: 3 inputs from the same (uncompressed) address produces a 583 bytes 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.
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)"

Quote
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?
Yes, exactly!

Quote
Also, would this be correct irrespective of the amounts being sent because what matters is the number of inputs on a transaction?
Yes, amount being transacted doesn't matter now. It used to for tx prioritize, but no longer.

HCP
Hero Member
*****
Offline Offline

Activity: 756
Merit: 932

<insert witty quote here>


View Profile
December 18, 2017, 10:49:57 PM
 #5

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?
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).


Quote
Also, would this be correct irrespective of the amounts being sent because what matters is the number of inputs on a transaction?
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 Wink


Quote
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.
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 Wink 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... Shocked Shocked Shocked

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 Tongue

DarkStar_
Legendary
*
Online Online

Activity: 1120
Merit: 1427

*dabs*


View Profile WWW
December 18, 2017, 11:07:07 PM
 #6

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
-snip-

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.

waldshmidt7
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
December 19, 2017, 09:14:36 AM
 #7

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.
showlar
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
December 19, 2017, 01:54:16 PM
 #8

No
cellard
Legendary
*
Offline Offline

Activity: 1162
Merit: 1150


View Profile
December 19, 2017, 02:06:15 PM
 #9

Quote
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

Thanks, this will be handy. What are the differences between compressed and uncompressed addresses, since when did Core implement this change? Also is it wallet dependent, or address dependent?

For example, a 2011 address will be sent as a compressed one in the latest version of Core, or it will be sent as uncompressed because it was created as uncompresed?

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
-snip-

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.

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.

ranochigo
Legendary
*
Offline Offline

Activity: 1568
Merit: 1094

Somewhat inactive.


View Profile WWW
December 19, 2017, 02:41:53 PM
 #10

Thanks, this will be handy. What are the differences between compressed and uncompressed addresses, since when did Core implement this change? Also is it wallet dependent, or address dependent?

For example, a 2011 address will be sent as a compressed one in the latest version of Core, or it will be sent as uncompressed because it was created as uncompresed?
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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!