Reusing receive address doesn't reduce tx size on spending, right?

[jnano]

Does receiving multiple times to the same address reduce the tx size when sending money from that address?
I assume not, because transactions refer to other txes rather than addresses. But maybe there are still opportunities to optimize something away?

[1714788265]

1714788265

[1714788265]

1714788265

[1714788265]

1714788265

[1714788265]

1714788265

[1714788265]

1714788265

[1714788265]

1714788265

[achow101]

Does receiving multiple times to the same address reduce the tx size when sending money from that address?
I assume not, because transactions refer to other txes rather than addresses. But maybe there are still opportunities to optimize something away?

No, it does not. On a technical level, addresses do not exist. What exists are transaction outputs. Receiving 100 times with 100 transaction outputs associated with the same address is no different from receiving 100 times with 100 transaction outputs all associated with 100 different addresses. When you spend those 100 outputs, the fee will be the same regardless of which addresses you used.

[jnano]

Is there any compression used in blocks in their native format?

[achow101]

Is there any compression used in blocks in their native format?

No, and there is not much that can be compressed. Most of the data in Bitcoin is pseudorandom so it compression algorithms can't compress it that much.

[jnano]

I thought maybe there are repeated tx ids, or auxiliary data that clients can theoretically add in.

I haven't checked raw network-format blocks, but compressing a few Core block .dat files, they reduce by about 20% (using a 1MB dictionary).
Maybe it's just an artifact of the on-disk database format.

[aplistir]

Does receiving multiple times to the same address reduce the tx size when sending money from that address?
I assume not, because transactions refer to other txes rather than addresses. But maybe there are still opportunities to optimize something away?

Reusing address does not reduce tx size, BUT
if you use P2PK instead of P2PKH you can reduce tx size considerably. Especially if you use compressed public keys.

When paying to an address with P2PK, you will pay to compressed public key which is 33 bytes. And 33 bytes is longer than the 25 byte bitcoin address used in P2PKH.  So when paying to your public key you actually have to pay fee for 8 more bytes.

On the other hand when you use coins that have been moved to your address with P2PK you will NOT need your public key AT ALL in the out tx. So you will  save 33 bytes for each unspent output. (or 65 bytes if you have an uncompressed key)

That is why it is a lot cheaper to use P2PK.

You can have both P2PK and P2PKH inputs in the same bitcoin address.

Is it a security risk? I don't think so. Yes, your public key will be visible, but currently cracking the private key from the public key is impossible. And even is someone could crack your private key from your public key, I am quite sure they would empty addresses with more coins that what you have.

For example, this address with 109203 BTC has its public key visible: 16rCmCmbuWDhPjWTrpQGaU3EPdZF7MTdUk

Very nice of them to "risk" their coins and being an indicator of when someone will crack ECDSA used in bitcoin.
In my opinion it is nuts to keep that  much BTC in one address. What if someone accidentally got an address collision with them?

P2PK is actually safer from address collisions that P2PKH. To be able to spend from P2PK input you have to use exactly your private key. There is only one of those. Paying from P2PKH input there are 2^96=79228162514264337593543950336 private keys that can be used. Finding one of them accidentally is that much more probable.

[aleksej996]

I thought maybe there are repeated tx ids, or auxiliary data that clients can theoretically add in.

You can't have two transactions with the same tx id in the blockchain, as tx id is calculated based on transaction contents. If that was possible you would be able to send the same transaction twice, meaning you would spend the same coins twice and double the balance of the receiving address.

In my opinion it is nuts to keep that  much BTC in one address. What if someone accidentally got an address collision with them?

P2PK is actually safer from address collisions that P2PKH. To be able to spend from P2PK input you have to use exactly your private key. There is only one of those. Paying from P2PKH input there are 2^96=79228162514264337593543950336 private keys that can be used. Finding one of them accidentally is that much more probable.

To be honest, address collisions are so unlikely that you are more likely to invent a quantum computer in your garage big enough to break those public keys and far more likely to lose one of the private keys if you keep your coins in multiple addresses. Pretty much anything in this world is possible thanks to quantum mechanics, but you have to be reasonable and not spend your time calculating practical impossibilities.

[achow101]

You can't have two transactions with the same tx id in the blockchain, as tx id is calculated based on transaction contents. If that was possible you would be able to send the same transaction twice, meaning you would spend the same coins twice and double the balance of the receiving address.

There actually are multiple transactions in the blockchain which have the same txid. These transactions are coinbase transactions included in blocks prior to the deployment of BIP 30 and BIP 34 (and were the impetus for BIPs 30 and 34). Only the most recent transaction of a transaction with duplicate txids is the one that is considered to be spent from and included in the UTXO set. The other transactions with the same txid have provably burned coins as they are unspendable. BIPs 30 and 34 have since disallowed duplicate txids and made it nearly impossible for duplicate txids to occur (except when there are hash collisions).

[jnano]

Is it a security risk? I don't think so. Yes, your public key will be visible, but currently cracking the private key from the public key is impossible.

But I suppose it doesn't matter if you intend to spend it shortly after receiving, since you expose the public key when paying with a P2PKH input.

Regarding the byte cost, I assume all modern clients always use compressed addresses? If the scripts in this answer are the minimum possible, compared to P2PKH, P2PK is +10 bytes to send to, but -34 bytes to spend from.

Is there a standard way to generate P2PK receive addresses? Aren't 1-prefix addresses just for P2PKH?

BTW, a few posts were deleted from this thread, which happens a lot on the forum. How come?

[achow101]

Is there a standard way to generate P2PK receive addresses?

No.

Aren't 1-prefix addresses just for P2PKH?

Yes.

BTW, a few posts were deleted from this thread, which happens a lot on the forum. How come?

A lot of them are spam or low value. I will delete posts from people who clearly do not read the thread and just post the same thing that someone else posted earlier in the thread.

[doctor-s]

Does receiving multiple times to the same address reduce the tx size when sending money from that address?
I assume not, because transactions refer to other txes rather than addresses. But maybe there are still opportunities to optimize something away?

No, it does not. On a technical level, addresses do not exist. What exists are transaction outputs. Receiving 100 times with 100 transaction outputs associated with the same address is no different from receiving 100 times with 100 transaction outputs all associated with 100 different addresses. When you spend those 100 outputs, the fee will be the same regardless of which addresses you used.

I want to add some definitions to this discussion as it was difficult for me to understand exactly what's talked about.

This is often the problem where very technical minded folks can't adjust their language to their audience. So here's some extra definitions

Output:
Output in a tx contains two fields: a value field for transferring satoshis, and a pubkey script for indicating conditions for those satoshis to be further spent.

https://bitcoin.org/en/developer-reference#compactsize-unsigned-integers


So the thing that I found it hard to get my head around, but now I understand, is that it doesn't matter if the coins are all at one address or multiple addresses. Because it's not relevant. Each tx you receive has a script that has certain criteria to spend the coins included in that tx. You need to satisfy the script for each tx to spend each coin. You can't just assume because all the coins are at one address they're the same. They're not.

Although...

That leads me to a thought.

Could you have all your coins sent to a single address, and then make a second transaction of all those coins once again to a single address? Would that reduce the UTXO set?

e.g,:

tx 0 > address 1
tx 1 > address 1
tx 2 > address 1
tx 3 > address 1
tx 4 > address 1
tx 5 > address 1
tx 6 > address 1

In this case UTXO set is 7. If I then did a transfer like this:

address 1 > tx 7 > address 1

Now UTXO set is 1


I believe it would work wouldn't it? It's a two step process but it would consolidate the UTXO set.

[achow101]

Could you have all your coins sent to a single address, and then make a second transaction of all those coins once again to a single address? Would that reduce the UTXO set?

Yes, you could do that. That would reduce the UTXO set. You wouldn't need to have all your coins sent to the same address in the first place, although if they were, there is then no harm to your privacy.

[jnano]

That brings me to something else I was pondering, but I'd better start a new thread for that...

[doctor-s]

Could you have all your coins sent to a single address, and then make a second transaction of all those coins once again to a single address? Would that reduce the UTXO set?

Yes, you could do that. That would reduce the UTXO set. You wouldn't need to have all your coins sent to the same address in the first place, although if they were, there is then no harm to your privacy.

I suppose the idea of consolidating coins at single addresses into single tx outputs pro-actively without user input would be denied due to the privacy implications and fees required? I guess there's no way around it and it's kind of a dead end to help with UTXO growth?

Thinking about it the best thing to do would be to manage the creation of txs better to minimise utxo,

e.g.

A single address has:
utxo a = 2btc
utxo b = 5btc

if you're making a new tx, you'd empty "utxo a" first, you wouldn't take 2btc from "utxo b" and leave 3btc remaining in a new "utxo c" controlled by the original address as that would be wasteful.

I believe the above is already being done? - *edit - yes. This is how bitcoin core operates. In fact it operates in a more sophisticated way.

*edit: found an old article discussing this very idea: https://medium.com/@lopp/the-challenges-of-optimizing-unspent-output-selection-a3e5d05d13ef

Perhaps what would be a useful suggestions is making UTXO transparent to wallet users.

I transfer random amounts generally. There's no rhyme or reason to the values unless they're direct payments. If I'm transfering to an exchange, I transfer whatever number I feel like.

It would make more sense if I could see that I have UTXO of value X, then I can choose a transfer of exactly that amount.

If this was transparent in the wallet and it advised the user "hey, match a UTXO or the sum of some UTXO and you will get lower fees". That could be beneficial in some way.

[Thirdspace]

BTW, a few posts were deleted from this thread, which happens a lot on the forum. How come?

yes, one of them was mine explaining in short condensed example of the benefit using compressed addresses
which apparently considered as low value post deemed for deletion 

Perhaps what would be a useful suggestions is making UTXO transparent to wallet users.

It would make more sense if I could see that I have UTXO of value X, then I can choose a transfer of exactly that amount.

now I will try answering this question, risking my post get deleted again 
if you use bitcoin core wallet, I don't use it so can't verify, I believe you can enable "coin control"
I'm saying this because all other altcoin wallets I use also have this "coin control" feature
with that you can just simply choose any unspent outputs you want and send them out
this feature is disable by default because it requires more depth understanding of bitcoin transaction

[doctor-s]

I believe you can enable "coin control"
I'm saying this because all other altcoin wallets I use also have this "coin control" feature
with that you can just simply choose any unspent outputs you want and send them out
this feature is disable by default because it requires more depth understanding of bitcoin transaction

You are correct, I just checked it out.

Looks like it's all been thought of and put in place.

[jnano]

Got delayed in writing that other post.
Tell me what you think: Balancing fees, time, UTXO set size, blockchain size

doctor-s, it's also related to your Opt in use of change addresses to decrease utxo? thread.