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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4DFB0C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 18:24:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 49BBC86418
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 18:24:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id haQ3ogw3bxM3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 18:24:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by whitealder.osuosl.org (Postfix) with ESMTPS id 2BEAF863CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Apr 2020 18:24:43 +0000 (UTC)
Date: Sun, 05 Apr 2020 18:24:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1586111080;
bh=Z5K90NuDQFkHcYA7Uu7DLrwtxxrd5r6PCC6G6iskUnI=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=YpwApIkBQEENOFREOAndHKt4mtB6Hs1aqwVpVGOeOD7mlKu3ITfXYB3fDR/AKY0Gz
D9mOqQOEPgyaxdDZfUVHrIDFGgqP1oWUCNt2ZYcflYj9hd69oTt3B4YOjjgcb50OWA
gsXz0MtgtAjz7tsuwlaZa9CfR6Rufx5FaC8sbCBI=
To: Bob McElrath <bob@mcelrath.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <GfczaOA5Y47fxbr2edrFWY04-3lyviBjGT9kOIqVCtGSOC4bv068SNrCh6RCqjpA33c5twzP-hT0Ijtk0bVn-MKSMSOlDkHrwfmYi-IhuVU=@protonmail.com>
In-Reply-To: <20200405141717.GN28113@mcelrath.org>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
<20200331103508.asvxujkhtifj6n7i@ganymede>
<CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
<CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com>
<CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com>
<20200405141717.GN28113@mcelrath.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Tom Trevethan <tom@commerceblock.com>
Subject: Re: [bitcoin-dev] Statechain implementations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sun, 05 Apr 2020 18:24:45 -0000
Good morning Bob,
> Note that this attack requires collaboration with the current UTXO owner.
> Generally if there's some form of address/payment request, the current ho=
lder is
> trying to transfer the UXTO to some other (non-statechain) entity, and he=
knows
> the target of the transfer, and participates in the protocol to authorize=
it.
> The current holder must obtain the target pubkey for the transfer out-of-=
band
> with respect to the SE, or the SE can MITM that.
>
> It's a stated security assumption that the sender or receiver do not coll=
ude
> with the SE. If either do, then your attack is generally possible and all=
bets
> are off. So what you've described is simply the SE colluding with the rec=
eiver.
> The receiver will already receive the UTXO, so the receiver here is assis=
ting
> the SE in stealing his (the receiver's) funds, or the SE has done a MITM =
on the
> transfer. Various improvements including blind signing, a SE-federation, =
etc
> are valuable to consider to mitigate this. But the SE must be prevented, =
one way
> or another, from "buying the UTXO". The SE cannot be allowed to be both o=
perator
> of the SE and a customer of it, as this clearly violates the no-receiver
> collusion principle.
>
> "Adding a new user key" doesn't change the situation. There's already a u=
ser key
> involved, and the user has already acquiesced to the transfer. Acquiescin=
g with
> two keys doesn't change anything.
The point is not that acquiescing with two keys is possible.
Instead, the point is that any past owner of the coin can collude with the =
statechain authority (who, in the new scheme, must be trusted to delete old=
keys), or anyone who manages to get backups of the statechain authority ke=
ys (such as by digging for backups in a landfill), in order to steal the on=
chain funds, regardless of who the current owner is, within the statechain.
Thus an amount of trust must still be put in the statechain authority.
So I think the security assumptions should be that:
* The statechain authority really does delete keys and does not make backup=
s.
* No *past* or *current* owner of the coin colludes with the statechain aut=
hority.
* I think saying merely "sender" is not sufficient to capture the actual =
security assumption here.
Regards,
ZmnSCPxj
|
