Date: Wed, 7 Aug 2019 20:10:17 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: Chris Belcher <belcher@riseup.net>
Message-ID: <20190807201017.2a03b971@simplexum.com>
In-Reply-To: <483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
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>
	<483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
 attacks using fidelity bonds
Precedence: list

=D0=92 Wed, 7 Aug 2019 11:05:41 +0100
Chris Belcher <belcher@riseup.net> 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 second scheme ("all locked TXO may be required to be spendable
by *any* key that controls any TXO in the 'bond TXO package'") is in
almost all regards the same as simple "require TXO to be consolidated",
and looks like it is not in any way better than simple consolidation.

The first scheme - 'allow revocation of the whole bond by the key
controlling even a single TXO in a bond' - might be more promising.

> 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.=20

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.
=20
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017217.=
html