From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1BB011AE5 for ; Mon, 28 Jan 2019 04:14:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4E92D1FB for ; Mon, 28 Jan 2019 04:14:50 +0000 (UTC) Date: Mon, 28 Jan 2019 04:14:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1548648887; bh=OqNWsp/SxiLzPYmm608NmvjprHEkcTWMcJ2FN7rbN5s=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=IAGnMKdbAp1wR7e8MH4HJFeecBvOvKdKcMtsydCuNhrlvRraDomzpv6ZYq/bRLyQT p/VUYyPtXJgtndEug72zAVhvB0zOaRusUkwZ5VoBi+zrpgrSVu37NfAVJ9+h+IZyIC YcNpGl5SZuBGPX+M5M6le69QgwG2DrW/gLkdCp2c= To: "rhavar@protonmail.com" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <-NShvd5jVPHb7_QmmjQMHX4f-O53noLWK8DKl37mJGcNlIvGoGbBrJVAwly9cHtLrB1tSz8FVL_wSMvaj2uAA760Sgr4Mg6M4VQuKZx0m7w=@protonmail.com> In-Reply-To: <-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com> References: <-yZhdFkKfKAEz1_4GKKSpTxjvR8EDSsH_5-TTh_4X5qwa79igXKR14rh6JASrald-F97o1htWY_kcBQ7IVr7ZH9zOQlOEwzhkWDjTq0d7F4=@protonmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 28 Jan 2019 06:15:19 +0000 Subject: Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 04:14:51 -0000 Good morning Ryan and Adam, > [UIH2 snipped] Perhaps I am being naive, but I seem, the B2EP and similar do not need to w= orry 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 outpu= t, input < output. >From the proposal BIP: > The receiver then adds one of his own inputs (known as the "contributed i= nput") and increase the output that pays himself by the contributed input a= mount. Suppose the original transaction avoids the UIH2 (i.e. for all inputs, ther= e exists an output, input < output). The single added input will also avoid the UIH2, since the contributed outp= ut 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 th= at 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 m= ay now exceed the largest sender input. But since there are more transactions that avoid the UIH2 than not avoid UI= H2, the increased probability of now avoiding the UIH2 will lead to a great= er anonymity set (especially for the sender, whose coin selection algorithm= might have a consistent bias that makes it create transactions that trigge= r 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 UIH= 2 checks at all, would be an improvement in both privacy and implementation= simplicity. Regards, ZmnSCPxj