From: Adam Gibson <ekaggata@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
Date: Mon, 28 Jan 2019 14:19:09 +0100 [thread overview]
Message-ID: <226c43d8-1fad-9d90-ba47-9230118e447d@gmail.com> (raw)
In-Reply-To: <-NShvd5jVPHb7_QmmjQMHX4f-O53noLWK8DKl37mJGcNlIvGoGbBrJVAwly9cHtLrB1tSz8FVL_wSMvaj2uAA760Sgr4Mg6M4VQuKZx0m7w=@protonmail.com>
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.
next prev parent reply other threads:[~2019-01-28 13:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 20:24 rhavar
2018-09-10 12:30 ` Sjors Provoost
2018-09-10 15:49 ` rhavar
2019-01-25 14:47 ` Adam Gibson
2019-01-27 7:36 ` rhavar
2019-01-27 12:20 ` Adam Gibson
2019-01-27 19:24 ` rhavar
2019-01-27 19:42 ` James MacWhyte
2019-01-27 22:11 ` rhavar
2019-01-30 2:06 ` James MacWhyte
2019-01-30 2:46 ` rhavar
2019-01-30 20:58 ` James MacWhyte
2019-01-28 4:14 ` ZmnSCPxj
2019-01-28 13:19 ` Adam Gibson [this message]
2019-01-30 8:34 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=226c43d8-1fad-9d90-ba47-9230118e447d@gmail.com \
--to=ekaggata@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox