summaryrefslogtreecommitdiff
path: root/e7/d5bd9fee24002adf73b758abbbdd0a2bb86f22
blob: a4441b43db626b2145a1ca99ebb9a466a14e7ed6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
Return-Path: <dp@simplexum.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 16A57C7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Aug 2019 15:08:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2AE0B7D2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Aug 2019 15:08:55 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
	by mail.ruggedbytes.com (Postfix) with ESMTPS id 686942600524;
	Wed,  7 Aug 2019 15:08:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
	s=mail; t=1565190533;
	bh=taLBZkrbujzrDx7ePOMmBhkMMwqUez+EqZhVbMFLO9Q=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=mU467zCBPWH3ZG/eDySiGGq6VjUaaicgrHGGFWk44i6L4Rt4EBDusI0Ks731JzA6f
	AigouRgJsWdMlttS1FpaDj3Xg/Pmj74Js9YzIvDOD08eVoPh9ftyKF+T/pnyzOk4dh
	35hR0UEAJKVSJWZx4fiCdj2jZdcpw/2M3I3+KsXQ=
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
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU 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 15:10:30 +0000
Cc: bitcoin-dev@lists.linuxfoundation.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 <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: Wed, 07 Aug 2019 15:08:56 -0000

=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