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 D4CADB3E for ; Tue, 6 Aug 2019 23:33:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 823834C3 for ; Tue, 6 Aug 2019 23:33:30 +0000 (UTC) Date: Tue, 06 Aug 2019 23:33:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565134407; bh=4JMmhR0DS3V1Q5RaUIY1mOw43lOLBajxv+RTShfQOTY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ln1/ieTS9yGZg5R7sMLxUJelFtDnHslt6yGb4Z5NO+Tu61CysiyAfUPX88Gdg0Kom wljnxa5lg2jhOxl9KS7g8tx/ba3nlK0ejLbfLHfH8TonacC9FDzqMd1KESc3rFTfis goYL3KV9UHas3XtIzOO4R0XGfLCX2p/tGovSlh+k= To: Dmitry Petukhov , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20190807023742.73750ba3@simplexum.com> 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> 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: Tue, 06 Aug 2019 23:33:31 -0000 Good morning all, It might be useful to remember that there exists pressure to pool proof-of-= work due to tiny non-linearities caused by Proximity Premium and Variance D= iscount flaws. Similarly, any non-linearity in any fidelity bond scheme exerts the same po= oling pressure. Deliberately increasing the non-linearity to V^2 worsens the pooling pressu= re, not lessens it. (I wonder if instead going the opposite way and doing V^0.999 might work be= tter; I have not figured all the implications of such a scheme and leave it= to the reader.) > Unfortunately, both described schemes fail the same way as > 'require TXOs to be consolidated by the owner', by the fact that with > muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in > [1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban > musig for the bonds' is not the answer, I believe. If my understanding is correct, efforts to expand ECDSA to more than two-pa= rty n-of-n "true" multisignatures already are ongoing. One might attempt to use transaction malleability as a protection, and requ= ire that transactions that put up bond TXOs should spend from at least one = ***non***-SegWit output, so that the scheme as described fails (as the fund= ing txid is malleable after-the-fact). But the scheme as described only considers ways to securely aggregate *with= in* the Bitcoin universe. I have recently learned of a spacce called the "real world", wherein appare= ntly there exist things as "contract law". It seems to me this "contract law" is a half-baked implementation of Bitcoi= n cryptographic smart contracts. By what little I understand of this "contract law", it would be possible fo= r an aggregator to accept some amount of money, with a promise to return th= at money in the future with some additional funds. If the aggregator fails to uphold its promise, then some (admittedly centra= lized) authority entity within the "real world" then imposes punishments (a= pparently inspired by similar mechanisms in Lightning Network) on the aggre= gator. Such arrangements (accepting some money now with a promise to return the mo= ney, plus some interest earned, in the future) apparently already exist in = this "real world", under the name of "time deposits". Regards, ZmnSCPxj > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/01721= 7.html > > =D0=92 Wed, 7 Aug 2019 01:55:41 +0500 > Dmitry Petukhov dp@simplexum.com wrote: > > > =D0=92 Mon, 5 Aug 2019 20:04:26 +0100 > > Chris Belcher belcher@riseup.net wrote: > > > > > So what's needed is a way to make renting out TXOs impossible or > > > very difficult. > > > > You can make renting the TXOs risky for the attacker. Make it so that > > the entity that rented out the TXO can revoke the participation of > > said TXO in the market, by publishing some special signature. That > > act of revocation can also mean revocation of all other TXOs that > > were used in a bond alongside it. This way, any entity that wants to > > spoil an attacker's consolidation via rent, can rent out its TXO to > > the attacker, and then revoke it, spoiling the whole package the > > attacker have consolidated. > > There may be other way to impose penalties. > > For example, all locked TXO may be required to be spendable by any > > key that controls any TXO in the 'bond TXO package'. I think this > > should be possible with taproot - you will have to publish a taproot > > trees for your locked TXOs (say, N of them), and the tree for each TXO > > will have N leaves, each leaf will specify a condition "spendable by > > the key N". This way, if I give you my TXO to include it in a bond by > > locking it, you also need to make your other TXOs in a bond spendable > > by me. > > For both scenarios to work for the attacker, there's need to be an > > off-chain contractual relationship between the parties. Otherwise the > > entity that rents out the TXOs can spoil or just confiscate the bond > > of the entity that rented them, without reprecussions. > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev