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
|
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 8CB3CF42
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 12:03:51 +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 0AF0E14D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 12:03:50 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id 6DA682600524;
Thu, 8 Aug 2019 12:03:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1565265828;
bh=NBmilLi0j/jQ8d7U9FpqqouxYcEXrtO42iSmBNYgoBo=;
h=Date:From:To:Cc:Subject:In-Reply-To:References;
b=DsLCGedsrA9y8zI86IHR7C7oZAIL7nJ6kUjVuOo+MqQS9o0Q2OC2g6dt4Ald6SPcH
mq9/tGMrTQa78aE7oBSNAUNhxSxrb97sKBge2s3gsSL/VJjdAUU/sZx3S5zz70DINA
sqfKXLgwXlS6V1RJULuxH2DYTlAcrgky453+md4o=
Date: Thu, 8 Aug 2019 17:05:05 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: Dmitry Petukhov via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190808170505.4169585f@simplexum.com>
In-Reply-To: <20190807201017.2a03b971@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>
<483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
<20190807201017.2a03b971@simplexum.com>
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,
TVD_PH_BODY_ACCOUNTS_PRE 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: Thu, 08 Aug 2019 12:16:03 +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: Thu, 08 Aug 2019 12:03:51 -0000
=D0=92 Wed, 7 Aug 2019 20:10:17 +0500
Dmitry Petukhov via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
wrote:
> 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.
>=20
> 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).
>=20
> 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.
The backout transaction might not be timelocked itself, but can depend
on another timelocked transaction (made specifically to avoid the
backout transaction be timelocked). That extra transaction will need to
be broadcast before the backout transaction.
To account for that possibility, takers would need to either use more
relaxed verification rules (do not check if the inputs of the 'snitch
transaction' exist), or would need to check the whole package of
dependent transactions in which the last one spends the bond.=20
|
