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 16A57C7F for ; Wed, 7 Aug 2019 15:08:56 +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 2AE0B7D2 for ; Wed, 7 Aug 2019 15:08:55 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 686942600524; Wed, 7 Aug 2019 15:08:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1565190533; bh=taLBZkrbujzrDx7ePOMmBhkMMwqUez+EqZhVbMFLO9Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=mU467zCBPWH3ZG/eDySiGGq6VjUaaicgrHGGFWk44i6L4Rt4EBDusI0Ks731JzA6f AigouRgJsWdMlttS1FpaDj3Xg/Pmj74Js9YzIvDOD08eVoPh9ftyKF+T/pnyzOk4dh 35hR0UEAJKVSJWZx4fiCdj2jZdcpw/2M3I3+KsXQ= Date: Wed, 7 Aug 2019 20:10:17 +0500 From: Dmitry Petukhov To: Chris Belcher Message-ID: <20190807201017.2a03b971@simplexum.com> In-Reply-To: <483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net> References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net> <94534006-D560-4C90-9D5D-A3A64B698518@gmail.com> <20190726143738.0be561da@simplexum.com> <3c328312-2bdd-60d9-7425-8db620d09abb@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> 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: Wed, 07 Aug 2019 15:10:30 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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: Wed, 07 Aug 2019 15:08:56 -0000 =D0=92 Wed, 7 Aug 2019 11:05:41 +0100 Chris Belcher wrote: > These are very creative schemes. At the very least they would stop the > easy mindless renting TXO method, where someone with coins on a > hardware wallet simply creates a signature and copypastes it into a > website to get free money. The second scheme ("all locked TXO may be required to be spendable by *any* key that controls any TXO in the 'bond TXO package'") is in almost all regards the same as simple "require TXO to be consolidated", and looks like it is not in any way better than simple consolidation. The first scheme - 'allow revocation of the whole bond by the key controlling even a single TXO in a bond' - might be more promising. > I wonder if there's a cryptographic way to prove that muSig and > 2P-ECDSA have not been used to create a certain pubkey/signature. In the second scheme, to revoke/spoil the bond, the entity that controls one TXO participating in this bond needs to simply prove that it somehow controls/have the ability to spend that TXO. In shared ownership rent scheme that ZmnSCPxj described in [1], the 'TXO rentier' has a signed timelocked 'backout' transaction that spends the locked TXO, and assigns the reward to rentier. If we say that any transaction that spends any TXO in the bond (ignoring the timelock), invalidates the bond when presented to takers, then TXO rentier can revoke the bond by simply publishing this transaction (not to the blockchain, but by some other means so that takers can receive it). The transaction validity can be verified, with the relaxed rules that ignores the timelock. After it is verified, takers mark the whole bond as revoked and will not consider it when chosing makers. One inconvenience here is that takers need to store the data about revoked bonds. But it seems to me that there's no need for that information to be synchronized between the participants instantly. It is enougth for takers to get the revoked-set eventually. The rentier are still incentivized to not spoil the bond, to receive the profit. Their funds are locked anyway. But if the goal of the 'rentier' is to attack the attacker, the opportunity cost of these locked funds is the cost of the attack. If the renter rents TXOs from several entities to include in one bond, revocation by one rentier spoils whole bond, and the total loss for all participants is bigger than the oportunity cost of locked funds of a single rentier that made the revocation.=20 The possibility of such revocation increases risk for the renter and would-be co-rentiers, and is likely limit the possible scale of such TXO-renting operation. =20 [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017217.= html