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 A8DD2CBB for ; Thu, 8 Aug 2019 00:09:16 +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 84F6A829 for ; Thu, 8 Aug 2019 00:09:15 +0000 (UTC) Date: Thu, 08 Aug 2019 00:09:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565222952; bh=zZpaXmuEjwbnZnp33LEbe6wBJLIUFy1bQi4mUvWr+sE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=XiFdLKk2pNuCTBuJXNZJ3x99IExsDYUDU7lUGY/4LAnAOBjSNLtBpXKicmiCv76fT FF9H8wPt/vIV9DfCf+RpwPr4FxIc4GnoaO4/Nc28dPkPWNdlm+qCaSa3A1LLJx6TVd fO4QHKLd4kU1YrmCqlvdTu9TqbicQC77jbZnbsoM= To: Dmitry Petukhov , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20190807201017.2a03b971@simplexum.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> 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 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 00:09:16 -0000 Good morning Dmitry, > The first scheme - 'allow revocation of the whole bond by the key > controlling even a single TXO in a bond' - might be more promising. Is it? I imagine any key can secretly be a MuSig or aggregated ECDSA key, with the= aggregator being a signatory. > > > 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. > > 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. This is quite a clever solution. Let me then attempt to break it. It is possible to encrypt data in such a way that it requires sequential op= erations in order to decrypt. https://www.gwern.net/Self-decrypting-files This basically allows us to encrypt some data in such a way that its decryp= tion is timelocked, by requiring a large number of sequential operations to= decrypt. It also seems to me (I am not a cryptographer) that it may be possible to p= resent a ZKP that an encrypted text, encrypted using the above timelock dec= ryption, is a signature of a particular message with a particular public ke= y. Thus, we can change the ritual to this: 1. I contact two lessors to aggregate their coins into a larger UTXO and t= hus break V^2. 2. We create a funding transaction that pays to a locked bond address, wit= h a pubkey equal to a MuSig among us. This spends the TXOs they want to lease out, as well as some of my fund= s to be used for paying for rent. We do not sign this yet. 3. We create a backout transaction that returns the bond to both lessors, = plus their rent. We partly perform the MuSig ritual to sign this transaction, with me as= the last step. 4. Instead of providing the completed signature to the lessors, I encrypt = it using the above timelocked encryption. I provide this encryption and a zero-knowledge proof that I have actual= ly completed the signature ritual correctly and that the timelocked-encrypt= ed text has the signature as plaintext. 5. The lessors now know they can acquire the signature by simply grinding = the timelocked encryption. This allows them to recover their money by the appointed time. 6. We then exchange signatures for the funding transaction and broadcast a= nd confirm it. Now, the lessors cannot provide a valid timelocked transaction, as they do = *not* yet have a complete signature; thus they cannot snitch about my aggre= gation of their funds. At the same time, they know that the timelocked encryption allows them to e= ventually get a complete signature and recover their funds. I can defray this cost of processing by increasing my rent slightly. Now of course we can just go one step further and also allow bonds to be sn= itched by presenting the timelocked-encrypted text and the ZKP that it cont= ains the signature for a timelocked transactions. But it seems to me that there is more than one way to skin this particular = cat, thus unless all ways to create provable timelocked encryptions are enu= merable, it would be possible to get around. (though of course it is dependent on a ZKP being possible for a timelocked = encryption) Finally, aggregation is still possible to insure by off-blockchain agreemen= ts, possibly with legal consequences, and thus entities like exchanges migh= t still be able to aggregate funds and acquire an undeservedly large weight= in the fidelity bond system. Regards, ZmnSCPxj