References: <TtjH2zicjKr8PBVCMOvA7ryt2z_XXvtrpC4y1wuWSxexNwMdbPGE7vPmu6UnzmfYqYBMxZ8NNoz4VUnODdIcjR4j-E1sYz_FA6ZZMjKHtuM=@protonmail.com>
	<e15c5dd7-6fe1-b253-e129-aeae6493acd1@gmail.com>
	<-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com>
	<-NShvd5jVPHb7_QmmjQMHX4f-O53noLWK8DKl37mJGcNlIvGoGbBrJVAwly9cHtLrB1tSz8FVL_wSMvaj2uAA760Sgr4Mg6M4VQuKZx0m7w=@protonmail.com>
From: Adam Gibson <ekaggata@gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=ekaggata@gmail.com; prefer-encrypt=mutual; keydata=
	mQINBFv0DQgBEADhaaCIS7omfkdE11EuLtyhjHTFGANwsrAkhf1eKYBMdHpC5jbPi2MgJWMk
	j5CMgvbKe+Y4vlUFzXW94uw8rMqH6Gd995+qs5EVqiA/8le80mTyuAG6JfpNqAo8ojHlPbr/
	9errq8kYNVfH5HhEJB2WEsFKFCB3L7IjukhroNzpSWCl2t8oCdLFtAorZiIBDIVXjMrJRCIP
	N4JhqV9O3PbXGiM2y+SIqwPemQF/qvwGfcSy+5OZ2TuDSPyGG7am8+a/kiq+s4prY/gJ2oxs
	i0iVtOMG48VRCHlg/LD5t82DYsHUpuZAXT7Ubz+ZI051vDPPutxR/op/7r2zkkWqrQUSoluL
	csUf+lb/3KSz8XkQwO9pLFC65qAqqBExKHAeh+uZnWDzn8E2JcpgDKYfW2eRZ4kL3PHozcZ6
	1Ek9JbSBWTj2ghTkuwCi6eH+E8ybtiqWeB25LfLhqs2Qnk2IzC5NtqwyU+poYZD/ya0PPdoN
	QVXsUB6F8j0M62bU25qqkkeUhW8aGDPVN0V/X4nCoyeUrOgU7oW9wCuFyg+eYn1q62iwCFrA
	rjGvKSv3LzdzIqHeM8gaEs2sjUnvxwlcjJDVdiEW0nngcGU5+czH06hD0Nvu4nAgXeE5s4wv
	d9FhGW9pjNb8TM2aQqMZzYJJDLNdVIZQNVycAtOwLKcCq0btFQARAQABtDNBZGFtIEdpYnNv
	biAoQ09ERSBTSUdOSU5HIEtFWSkgPGVrYWdnYXRhQGdtYWlsLmNvbT6JAjcEEwECACECGwMC
	HgECF4AFAlv0Dk0FCwkIBwMFFQoJCAsFFgIDAQAACgkQFBABoa938guczQ//f38lBKjg7c+U
	t31x5ciX1LtxvLyfnmTIDQRq4pB2FWrl14utkK4afDRwcBR6zRlQx8PE52+M9Rg7+KYQ7hDY
	y9c3IQonL2KdZgj+q2x99t5uUR9fj8b18U/2VDkVn1m8L//U3m596zZLwVBPr4OQ2Rd/rC6Y
	GznMNXSN97nNr7SPGLXYH3rUEcmBf4VklneO6/M5y0PgNdTTM4DyKfrCk9ailWtev06G6gvT
	kyLzjpHHZ5IyZvhpHua/oUHjeRzuS4VYUYQuuiATD7raJhXsxfL7g/NF/fOi3KwvRlAm4ns1
	fOxOInLD2QK5hiEjdlPixwmuLMtTdHk5dAM+QX8Hr2Tis/cN+5J7vpvZoP7L0M7XxYo9J6wV
	RMKOxNeFNa88W/n+pBDVCUdTqDOrVHP632zXt0sbaSKXa/KqznD+ReGOjaYsKKenEmyXgfv+
	WoaUoqn9uZ8R2MywWyKojYguTP+RLHtzuiN3GPFPXQban27Ah+M5d6ruh/P/AXyuddtibq36
	baD3iOXcGlmvfaAhYCVE59a3/AIAIZmkJr1DLJkfdF38BIqs+2/5jC05QyuGI94zmYy7Ivfj
	w8ncqUUpir2M6X25YD00AzNruXDFVz8mpU3RcHEyVAhBtQeZuB+d8pZMzROoXpY0K+VwM4VD
	3jiOJKQzYb+/kcaj20j9slS5Ag0EW/QNCAEQALueFahxEGALaZcBdBTYk5W32wdjdoZEjMUc
	z7iWFyArDHeXjmxAis3+Q6TkFlAuJhGHL0NVpHjqDe0wg5B0V/c+Ew3WJTS6Or8UmKKg/OjU
	b9gbRMmy+Jxm2Y7D8Lx7ikct3jo0aXJHApVzvFzQOUZUCO67/5PS9LY6RMqoyV97xnlaypsx
	9CUF9Fc0eK7U/rliUJ0cSKoKm8kI1QTUfgRXkm33tn1qX5piAO8iyzPLZlJC0sVkI6tG0NMX
	8d8/ifNmCZolBaYT8Y/J7tQgbdshMi7NSzpuPdZfeSo5JHIaQcBQCrjVPQvtWyQbVhbUKOFx
	qLqIkaMEwOTVBNAMxuvwWLfr9sCiCpbPGTdu5ujyI4JsdxT+LkwgQSPPC0CZpxbNFeOdKcQM
	o0f5la7zwNvEgXu0r9DGUAqM7cHPUUP0RQQl72vk1B2rr33gONeG8EzTYwYfuX5jjjyrd0Py
	9XAgg3b9RFxRIsTmzTzsAmyxRRBJmwBsEJ/8A8mLlEWhgDDn/gl23YfTBlV/J/PBN0vVFrSe
	IZtmWaDuxhiI07B/y1NKtttTkrU9R3K7GIinlIZ0/CR7LZRyP0F5NGLsDQwcrSNPLGoCeYLn
	9cSYCtQjZjAXCBDbPFQqq8LV7INtGXHG8FUoclibHU13eK1SBiSY836lwt4PlZ/IiVsmvMBX
	ABEBAAGJAh8EGAECAAkFAlv0DQgCGwwACgkQFBABoa938gsiOhAAtOQG/+Hh5vlk1r+AdFCO
	kgLCFlNqGWk4pLlAhpxmE5NVJKfqjjb+0AA9u8WpEmJAudw0vUQNC/fBHQFT8czKy4u7QFSk
	IPo2NtcGXYFjxMwzya5G87EgSgw8rekNHlC87r0lbcN/YZY3R0apcMCrbagjL7H4CGrc1oDl
	YSRqiwekkItKLNpv3RocHI/SQDcGdJAtq/K5S3kKxwGPKLG+8Tdau4WkPWG+YnPj594mNGJv
	5ZHUlma5r5hJHPSQregaDGJnq+ln3jDZ21rUEu1DROBP2UmS517WSiSZz+hQqgnRlXVql42f
	vsggFpL3zdOXq0UbqPee1FVOuUidXaA8dGBfujJ/4MjCfCt5zyhr1+l3tKVjDiQhUkFbMaNp
	fEUueW1gJuVgzofLmAhf3pTGiQQDpjKlijPLQxwAuQ4lM2KZObGSxDyw8Ffn8XX05DwU/s2h
	/MKuRgYyp20UiVUmdnZ/+KrH/KhFgh9dn7fueWh//4AaDAZ8NJruondaLkmZ+D53V4qsbJE3
	cpd1sXg5JL7eWE/8rwDsNWaJtM2p3viUujprCL7IMnXzv0dLfZm3fPGPWTg96/pdlWmpg4Ky
	QjnH5SYgtHM+2GQnUD5nwsOGbXU27qQDMCpWU8aDvz2LPyD4qx9sS0gPpvOAYK5S3c0lWB5y
	nl9Ca4x7aeV2qGM=
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <226c43d8-1fad-9d90-ba47-9230118e447d@gmail.com>
Date: Mon, 28 Jan 2019 14:19:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <-NShvd5jVPHb7_QmmjQMHX4f-O53noLWK8DKl37mJGcNlIvGoGbBrJVAwly9cHtLrB1tSz8FVL_wSMvaj2uAA760Sgr4Mg6M4VQuKZx0m7w=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver
 coinjoin protocol
Precedence: list

ZmnSCPxj, thanks, responses inline.

On 28. 01. 19 5:14, ZmnSCPxj wrote:
> 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.
> 
Yes, I had noted this (see link below).

> 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.

(Just to note (see link below) what I'm sure you're aware of but a
reader might forget: if the change output that the sender provided is
larger than the payment amount, the above won't happen).

> 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
> 

Really good point, and I think your argument is reasonable, if not
watertight. (Just in case you missed it I tried to outline an algo to
let the receiver avoid UIH2 on best effort basis here:
https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e#gistcomment-2799709).

Although I ~ sorta agree, there is a slight counterargument: receiver is
adding utxos, so in the absence of any transaction inspection you're
creating a different distribution than one gets from existing wallet
selection algos. For example:
Note that the most likely/desirable/considered use case may be a
merchant use case (after all, who receives coins most frequently? in
theory, people selling stuff), and it is highly plausible that they
might concentrate larger and larger sums into utxo(s) via use of
PayJoin. Completely mismatched input sizes could be a problem, it's
debatable, and it's also debatable whether it can be avoided, but what I
don't quite buy is that this issue can just be ignored.

And I'm reminded that a related point is made by belcher in the gist
comment thread iirc (after we discussed it on IRC): over time a
"PayJoin-only" merchant doing the simplest thing - using a single utxo
over and over again, will concentrate more and more funds into it, and
inevitably violating UIH2 in an increasingly dramatic fashion
(contributing a 100BTC utxo to a 0.1BTC payment etc.). Suggesting it's
better if there's a mix of payjoin/non-payjoin.