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 77462F30 for ; Thu, 8 Aug 2019 13:59:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 745D08A0 for ; Thu, 8 Aug 2019 13:59:20 +0000 (UTC) Date: Thu, 08 Aug 2019 13:59:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565272757; bh=Ti25AjaepT2xyFBaGN0i6ysw8gv7Sk07GVkmZOc2dUo=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=qqLKvP7EILWmTlbJhwEyM1958dV44ONdiQ9MG/2p0SsWF119m8glU98m+oYi5KM+v Be3mRjTK9BURhxy1c/FORhVM8ys1c1EXwTLQAGgpK49gzS6J4Bgju/7cRv8Z0A5hao En1EJYzVj9BHrUrP7HQ+8AEyHth9TZdxp9O5ppxQ= To: Dmitry Petukhov From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20190808163750.57f4e620@simplexum.com> References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net> <20190807015541.3d8aa849@simplexum.com> <20190807023742.73750ba3@simplexum.com> <483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net> <20190807201017.2a03b971@simplexum.com> <-6u9Ut_oYRThO21GIO1G8u4LpKavq2okw0Z7KoIM0tgwg4mAYXt2TP-SgiigMofdvLhvRuwX_q7Op6DUDM_eWUCjGmIEL_VTLpAeYDNOl5c=@protonmail.com> <20190808163750.57f4e620@simplexum.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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds 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: Thu, 08 Aug 2019 13:59:21 -0000 Good morning Dmitry, Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, August 8, 2019 7:37 PM, Dmitry Petukhov wro= te: > =D0=92 Thu, 08 Aug 2019 09:35:24 +0000 > ZmnSCPxj ZmnSCPxj@protonmail.com wrote: > > > OP_CHECKSIGVERIFY > > OP_CHECKSIG > > This anti-snitch protection won't work if there are two snitches, which > is concievable in the case of a large-scale consolidated bonds (one > entity can pretend to be two independent entities with two different > TXO). The snitch co-conspirator will refuse to sign the punishment > transaction. > > If you change the MuSig(all_except_snitch) to 1-of-n multisig > construction so that anyone other than the actual 'snitch' can > confiscate the snitch-bond, then there's possibility that that a > co-conspirator can get that bond before others - even before > the sntich transaction is distributed to takers. The correct way to do this, as with any offchain technique, is to have the = punishment transactions signed by the MuSig-of-everyone-other-than-punishme= nt-target before you even sign the funding transaction. If consolidation is subsidized by paying rent out to the consolidators, the= n the lessee of the UTXOs adds its rent payment in the same transaction tha= t atomically instantiates the fidelity bond and all revocable bonds as a si= ngle CoinJoined transaction. If any participant refuses to sign the punishment transactions of their co-= consolidators, then the lessee refuses to sign the funding transaction and = nobody earns any rent and the lessee goes look for another set of UTXO owne= rs (or just kicks out the participant who refuses to sign and lives with th= e smaller fidelity bond, no big deal). Of course, anyone renting consolidated bonds can themselves be unironic vic= tims of sybil attackers who split up their funds to smaller parts so that t= heir liability when later snitching is reduced, possibly to a level that is= comfortable to them. The sybil attacker then pretends to be lessors of UTXOs. > > It seems that to reasonably protect from more than one snitch with this > punishment scheme, you want to make a multitude of taproot leaves where > each leaf can be spent by cooperation of N entities, where N is the > size of expected non-snitch participant set. > > > Finally, aggregation is still possible to insure by off-blockchain > > agreements, possibly with legal consequences, and thus entities like > > exchanges might still be able to aggregate funds and acquire an > > undeservedly large weight in the fidelity bond system. > > This seems to me like the most immediate problem for the discussed > system. > > Since the centralized exchanges or other custodial services already > control TXOs of their customers who sent their funds there, they can > use them to make extra profit with joinmarket, and create fidelity > bonds out of these TXO with (or without) consent of the customers, and > pay them (or not) the amount according to their UTXO, while getting the > consolidation benefit of V^2 for themselves. It is also more probable > that such centralized custodial services would be willing to > participate in a deanonymization efforts, so that they can explain > their participation in coinjoins to regulators. Yes, down with the V^2 superlinearity, it is too strongly centralizing. Regards, ZmnSCPxj