Intrigeri,
> Hi,
>
> s7r:
>> intrigeri wrote:
>> The text was copied from Electrum man page.
> Thank you!
>
>> UTXO's are basically the coins you can spend. The spendable coins are in
>> UTXO's, not in addresses. Addresses are just a smart crypto way to let
>> the world know in advance who has the right to spend a given UTXO.
>> Existing unspent outputs cannot be reused, they are burned and re-crated
>> entirely every time. So you cannot spend part of a UTXO, you spend it
>> all (practice does not recommend re-using addresses - it's true nothing
>> keeps you from receiving the change in the same initial address that you
>> spent from, but you'll have a different UTXO).
> Yes, I had to learn all that last week already, but thanks anyway :)
>
> 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.
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.
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."
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.
>>>> Routing transaction relay through Tor is only part of the solution. The blockchain is
>>>> a public ledger that can be analyzed anytime after the initial transaction broadcast.
>>>> Private coin selection impedes correlation of transaction inputs and outputs that
>>>> could link back to an identity.
>>> Sure. I hope our doc clearly states that it's very hard to use Bitcoin
>>> in a privacy-preserving way, for some various value of "privacy".
>> Agreed, but the setting indicated by Michael could be shipped as a
>> default imho. It makes sense in a context like Tails/Tor threat model.
> Sorry if I was unclear: I'm not arguing this point. I didn't look into
> it in details, so I am really not in a position to have opinion about
> it yet. It's clear to me that there's no way to optimize coin
> selection for all possible desired outcomes (e.g. optimizing the
> blockchain itself, optimizing usage of unspent outputs i.e.
> not wasting money via fees on the long term, optimizing some kind of
> privacy on the short term), but it's not obvious to me which way Tails
> should lean towards: at this point I have no idea if the (limited)
> privacy benefits brought by this feature outweigh the drawbacks it
> brings in other areas.
I think that the privacy benefits are more substantial than you think
and transaction fees should be about the same. Consider the fact that
the current method spends across multiple addresses in a single
transaction confirming in that transaction and future transactions that
a single identity owns all of those addresses.
>
> Anyway: I personally don't feel responsible for maintaining the
> Electrum integration in Tails, would rather not to become more
> involved into it, and will therefore let its maintainer (i.e. anonym)
> make the call. But I'm genuinely curious about the unspent outputs
> optimization claim; I bet my intuition is wrong, and I'll learn
> something along the way :)
>
> Cheers,
Anonym, I did not expect this to be a controversial change. If you also
think that it is controversial, then maybe we should keep it disabled
and let the user decide.
Cheers,
Michael English
