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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
