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 676FEC4E for ; Tue, 6 Aug 2019 02:54:23 +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 AB795829 for ; Tue, 6 Aug 2019 02:54:22 +0000 (UTC) Date: Tue, 06 Aug 2019 02:54:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565060060; bh=WiYH3qNPyVC+lZoDjWRRBp/3pejHQ2cr2Wx3M5Ffx7Y=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=InsSTBXQZtgbQVqQmq6AQBhjZtns8CP3siCKB6V9tqmBqWuACd/TQQ5MKwAuUpvAd GPImiLgNopT360Lt84RN/lDNyHS8/pTDRTYruCKj8H6yq4VygmpOcI32FvPiukC5cv XN/JoLstyRFBCYn3g2xEoXNDVNfMqFI2KUWZLCNc= To: Chris Belcher , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: 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> 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: Tue, 06 Aug 2019 04:39:26 +0000 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: Tue, 06 Aug 2019 02:54:23 -0000 Good morning Chris, > This could be worked around by honest makers because they > can consolidate TXOs on the blockchain, which rented TXO owners can't do > because the TXOs are owned by different people. Would it not be possible the below? * I rent some funds from Dmitry. I agree to pay him 0.5 BTC for this service of putting up 50BTC from Dmit= ry UTXO. * I also own 50BTC myself in a separate UTXO. * We create a funding transaction paying out to a Schnorr MuSig output that= is 2-of-2 between us. This spends Dmitry UTXO 50 BTC and my UTXO 50BTC. We only create this yet and do not sign. * We create a backout transaction, probably with `nLockTime`, paying out 50= .5BTC to Dmitry and 49.5BTC to me. This spends the funding transaction. We sign this using MuSig. * After we exchange the signatures of the backout transaction, we exchange = signatures for the funding transaction. * Now we have a common 100BTC UTXO (indistinguishable from other Schnorr si= ngle-sig UTXOs) that can be used as fidelity bond for me. This is the output of the funding transaction. The above can be scaled up so I can rent arbitrary amounts of coin from man= y different people, who are assured of getting their funds back, in exchang= e for a fidelity bond / advertisement, and thus greatly destroying the prop= erties of the V^2 tweak. (The ability to have shared ownership of UTXOs is a powerful feature of Bit= coin, and backs its ability to scale, as witnessed with Lightning Network a= nd channel factories.) Regards, ZmnSCPxj