feature: Enhance privacy by change obfuscation

Application: Bitcoin Core

Feature: Enhanced privacy by change obfuscation

Operation: Provide a user selectable 'Enhanced privacy' option for transaction creation, when true the transaction randomly distributes change across up to twenty output addresses (minimum five?), provided each output is not dust.

Suggestions: Perhaps limit the total random number of addresses to distribute to by change amount. Optionally: If necessary, additional inputs can be selected if available to increase change although consider if this may eventually result in a decrease in obfuscation in some cases when the outputs are spent.

Issues: Transaction cost will be higher for the initial spend with the change due to increased outputs and, possibly for later spending the change depending on the future spend amount(s) and the number of inputs required.

Argument: If transaction linkage is possible, it is still possible with the obfuscated change but, it is far more difficult to guess what was retained by the owner of the originating utxo's unless the new change outputs are spent together in the same transaction.

Regards,

Damian Williamson

Damian Williamson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> writes:

> Operation: Provide a user selectable 'Enhanced privacy' option for
> transaction creation, when true the transaction randomly distributes
> change across up to twenty output addresses (minimum five?), provided
> each output is not dust.

This would be really expensive for the network due to the bloat in UTXO size, a cost everyone has to pay for. Not to mention the fact that it doesn't really seem that private, as the wallet is likely going to have to rejoin those inputs in future transactions (and the user will have to pay a high transaction fee as a result).

Alright, but even if two (or more) of the change outputs were linked in a future transaction, no-one can tell if they are still linked to your wallet or not unless there is also an additional re-used address on the new transaction input side that has also been previously linked to one of the inputs on the transaction creating the change.

Yes, I understand the additional cost but still thought it worthy of consideration.

Regards,

Damian Williamson

________________________________ From: Evan Klitzke <evan@eklitzke•org> Sent: Sunday, 18 March 2018 4:50:34 PM To: Damian Williamson; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] feature: Enhance privacy by change obfuscation

Damian Williamson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> writes:

> Operation: Provide a user selectable 'Enhanced privacy' option for
> transaction creation, when true the transaction randomly distributes
> change across up to twenty output addresses (minimum five?), provided
> each output is not dust.

This would be really expensive for the network due to the bloat in UTXO size, a cost everyone has to pay for. Not to mention the fact that it doesn't really seem that private, as the wallet is likely going to have to rejoin those inputs in future transactions (and the user will have to pay a high transaction fee as a result).

> This would be really expensive for the network due to the bloat in UTXO size, a cost everyone has to pay for.

Without commenting on the merits of this proposal, I’d just like to correct this common misperception. There is no necessary additional cost to the network from the count of unspent outputs. This perception arises from an implementation detail of particular node software. There is no requirement for redundant indexing of unspent outputs.

e

I note that Electrum v3.0.6 has an option to use multiple change addresses. It is off by default.

Regards,

Damian Williamson

________________________________ From: Eric Voskuil <eric@voskuil•org> Sent: Monday, 19 March 2018 5:59:28 AM To: Evan Klitzke; Bitcoin Protocol Discussion Cc: Damian Williamson Subject: Re: [bitcoin-dev] feature: Enhance privacy by change obfuscation

> This would be really expensive for the network due to the bloat in UTXO size, a cost everyone has to pay for.

Without commenting on the merits of this proposal, I’d just like to correct this common misperception. There is no necessary additional cost to the network from the count of unspent outputs. This perception arises from an implementation detail of particular node software. There is no requirement for redundant indexing of unspent outputs.

e