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 020B2E39 for ; Wed, 7 Aug 2019 11:35:41 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 438CD7D2 for ; Wed, 7 Aug 2019 11:35:40 +0000 (UTC) Date: Wed, 07 Aug 2019 11:35:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565177737; bh=rFZWB1OjYRhnaMkXqmcGI1x7OlpMv3HqjHqxQZi3LWc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=lqB8Hrhdrk6usPvllRBDqmZZUv+Rw6UnIV/btAb3VqKZie1Bfy55H+TR9Iccy5AyC +eqs++94XRYK4yH5OI6FvDFeo+gMgMl6+McuEzAyuAA2d2xyxXYkpnbCIw+H0rGeEk 0w1SHJ1NahXyB8rnxvYKJLZ7wFMZMH0WV63/hZHk= To: Chris Belcher , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net> References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net> <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> 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: Wed, 07 Aug 2019 12:04:18 +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: Wed, 07 Aug 2019 11:35:41 -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 Wednesday, August 7, 2019 6:05 PM, Chris Belcher via bitcoin-dev 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 workaround scheme with shared ownership of TXOs > requires brand new wallets to be created and hodlers must trust the > wallets enough to move their coins and hold them there for a long time. Possibly not so much? The wallet need only sign two things: 1. The fidelity bond itself. 2. The backout transaction. Both can be done in a single session, then the private key involved can be = erased permanently from memory. Only the signature for the backout needs to be stored, and this can be safe= ly stored without encryption by publishing to any cloud service --- others = getting a copy of the signature does not let them change the signature to a= uthorize a different transaction. It would be enough to write the signing code in C and use special OS calls = (which most languages higher than C do not expose) to allocate memory that = will never be put in swap. Then generate the private key using that memory, then clear it after usage = before deallocating to the OS. I believe `libsecp256k1` makes this easy. Unless part of the bond process requires that the taker do a challenge "sig= n this random nonce for me", but of note is that it would have to impose th= is on all makers. But if so, consider again this: 1. There exists two non-spying makers with nearly-equal bond values. 2. These makers need to keep their bond private keys in hot storage. 3. I approach both makers and offer to aggregate their bond values, formin= g a new bond with 4x the weight of their individual bonds, and split up the= increased earnings between us. This can be made noncustodial by use of smart contracts on Bitcoin. 4. It is no different from the point of view of both makers: they still ne= ed to keep their bond private keys in hot storage. But this way earns them more money than operating as non-spying makers. 5. I earn not only the fees for JoinMarket, I also earn additional fees fo= r spying on CoinJoins. It still seems to me that adding the V^2 tweak weakens the bond system, not= strengthens it. Regards, ZmnSCPxj