Date: Tue, 06 Aug 2019 23:33:19 +0000
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
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
	attacks using fidelity bonds
Precedence: list

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