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 

bitcoin-dev mailing list

Reply via email to