Hi,
Michael English:
>> Still, this doesn't answer my question of why the setting called
>> 'privacy' "helps to reduce blockchain UTXO". I would love to
>> understand, if someone is kind enough to explain it to me.
> I will try to explain to you what I think Electrum meant by reducing UTXO bloat. I am
> not a good teacher, but I hope that this helps.
Thanks *a lot* for taking the time to explain :)
> Honestly, reducing UTXO bloat depends on the circumstance. I will explain a few
> circumstances below. The UTXO set is most likely to be reduced by the "privacy"
> setting in a circumstance where one address has received three or more inputs.
> There are three cases for transaction inputs and outputs:
> 1. Find exact change
> 1. This case is very unlikely unless transaction creation is hand
> optimized. For example, let's say that I want to donate 0.01 BTC
> to Tails ;) and I find that I have a UTXO of 0.012 BTC. I could
> decide to spend the extra 0.002 BTC to protect my privacy and
> save a small amount on transaction fees. In this case, the UTXO
> set is not changed since there is one input and one output.
ACK. Of course, this is less unlikely if one considers unspent outputs
that are held by *all* addresses in a wallet, but it's still unlikely
and that's a detail.
> 2. Use Electrum's "priority" coin selection that uses older and
> larger value UTXO first
> 1. This case is likely to use a single large value UTXO and produce
> two outputs since one output has to be the change. The extra
> output created by this transaction could be considered "bloat."
Sure. And assuming it works exactly like that, on the long term this
contributes to ending up with tons of small unspent outputs that will
be hard to use without spending substantial fees, unless manually
combined with other, older/larger ones (been there, done that, not
exactly my cup of tea).
I have to say I'm a bit surprised that the algorithm works this way.
I find it a bit simplistic, but really I'm not pretending it would be
easy, or even doable, to make it better. From my (relatively newbie)
perspective, I would have expected that it would balance these two
factors with trying to 1. find exact change; 2. add tiny unspent
outputs to the transaction to optimize *future* fees and benefit from
the small fee required by the other, older/larger ones to avoid
increasing the fees for the transaction being constructed too much.
If the algorithm worked the way I would have naively expected, then
looking at unspent outputs held by *all* addresses would help with
reducing fees and UTXO bloat (compared to looking at only one
address), not only for the transaction that's being constructed, but
more importantly on the long run.
> 3. Use Electrum's "privacy" coin selection that prioritizes the
> number of UTXO in an address (and also optimizes change which we are
> trying to avoid)
> 1. This case takes several medium to small value UTXO and combines
> them into two outputs. If the number of inputs are three or
> more, then this could be considered reducing UTXO bloat.
ACK.
Thanks again for teaching me and fixing my naive expectations!
Cheers,
--
intrigeri
