Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Ryan and Adam,

> [UIH2 snipped]

Perhaps I am being naive, but I seem, the B2EP and similar do not need to worry about UIH2.

From the github discussion:

> "UIH2": one input is larger than any output.
.
I.e. there exists an input, for all outputs, input > output
To avoid this, we should ensure that, for all inputs, there exists an output, input < output.

From the proposal BIP:

> The receiver then adds one of his own inputs (known as the "contributed input") and increase the output that pays himself by the contributed input amount.

Suppose the original transaction avoids the UIH2 (i.e. for all inputs, there exists an output, input < output).
The single added input will also avoid the UIH2, since the contributed output value is added to the receiver output, thereby ensuring that contributed input < output.

Suppose the original transaction does not avoid the UIH2.
The receiver adding their own contributed input would then have a chance that the addition on the output will now cause the final transaction to avoid the UIH2, since the sum of the receiver amount and the contributed input may now exceed the largest sender input.
But since there are more transactions that avoid the UIH2 than not avoid UIH2, the increased probability of now avoiding the UIH2 will lead to a greater anonymity set (especially for the sender, whose coin selection algorithm might have a consistent bias that makes it create transactions that trigger UIH2).

So it seems to me that the simple solution, i.e. sender uses standard coin selection algorithms already in use today, and receiver does not do any UIH2 checks at all, would be an improvement in both privacy and implementation simplicity.

Regards,
ZmnSCPxj