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 23591C8B for ; Thu, 8 Aug 2019 11:37:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A21A82D for ; Thu, 8 Aug 2019 11:37:43 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 56BF52600524; Thu, 8 Aug 2019 11:37:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1565264261; bh=c59OGgNLG8WyTV6XWyYVYTUPXIV88kcNp+H4kDJtGvA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZovAKRXHTi/+UC2fRrxlogzztnqEIROkaxaW8cMyoTD4Se5kcVGRLKBHCfdYndcz/ /nSzf6B8Q0LwhT8GGQZXr83SZe3E9Kb0ct+CmgggXoyR/7WD5CtitlsbjS5hOAoT70 uqJFo/so7rQsnfrmKo0/oy1dc+H+z8k2kfJGW3dw= Date: Thu, 8 Aug 2019 16:37:50 +0500 From: Dmitry Petukhov To: ZmnSCPxj Message-ID: <20190808163750.57f4e620@simplexum.com> In-Reply-To: <-6u9Ut_oYRThO21GIO1G8u4LpKavq2okw0Z7KoIM0tgwg4mAYXt2TP-SgiigMofdvLhvRuwX_q7Op6DUDM_eWUCjGmIEL_VTLpAeYDNOl5c=@protonmail.com> References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net> <20190731205018.10ed4302@simplexum.com> <20190802145057.7b81c597@simplexum.com> <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> Organization: simplexum.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU 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: Thu, 08 Aug 2019 12:03:26 +0000 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 11:37:44 -0000 =D0=92 Thu, 08 Aug 2019 09:35:24 +0000 ZmnSCPxj 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. 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.