diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-08-06 23:33:19 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-08-06 23:33:31 +0000 |
| commit | 1c5c69e118f136bfea88978496a48603afb83a61 (patch) | |
| tree | d4053fa1563931b54baf7aee9df4106619c901b1 | |
| parent | 7d07360ed29c66f28baf6747216fc06e4a84a590 (diff) | |
| download | pi-bitcoindev-1c5c69e118f136bfea88978496a48603afb83a61.tar.gz pi-bitcoindev-1c5c69e118f136bfea88978496a48603afb83a61.zip | |
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
| -rw-r--r-- | 8d/1f8aa2f2bb35c387c692e0082fbd19858e3d8a | 154 |
1 files changed, 154 insertions, 0 deletions
diff --git a/8d/1f8aa2f2bb35c387c692e0082fbd19858e3d8a b/8d/1f8aa2f2bb35c387c692e0082fbd19858e3d8a new file mode 100644 index 000000000..56cb34b26 --- /dev/null +++ b/8d/1f8aa2f2bb35c387c692e0082fbd19858e3d8a @@ -0,0 +1,154 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D4CADB3E + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <dp@simplexum.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <j-MXLs8fEpx57ttA_3TbcaWXT_eGjpcFkFE-Yzy3aPrUhSmnSSwHS1zIuez4aoBp8VrIsGHL8sAWYc_vR_T6QgQXM4xCDrVVlv0uW9MIs5s=@protonmail.com> +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> + <ae32dcbb-c950-3b3f-22b9-d152d6b221cb@riseup.net> + <20190802145057.7b81c597@simplexum.com> + <ad501873-8912-765e-8df5-c9b0451fcd0a@riseup.net> + <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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + + + |