From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "rhavar@protonmail•com" <rhavar@protonmail•com>,
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 04:14:41 +0000 [thread overview]
Message-ID: <-NShvd5jVPHb7_QmmjQMHX4f-O53noLWK8DKl37mJGcNlIvGoGbBrJVAwly9cHtLrB1tSz8FVL_wSMvaj2uAA760Sgr4Mg6M4VQuKZx0m7w=@protonmail.com> (raw)
In-Reply-To: <-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@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
next prev parent reply other threads:[~2019-01-28 4:14 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 [this message]
2019-01-28 13:19 ` Adam Gibson
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='-NShvd5jVPHb7_QmmjQMHX4f-O53noLWK8DKl37mJGcNlIvGoGbBrJVAwly9cHtLrB1tSz8FVL_wSMvaj2uAA760Sgr4Mg6M4VQuKZx0m7w=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rhavar@protonmail$(echo .)com \
/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