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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Return-Path: <s7r@sky-ip.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 545228A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Aug 2016 10:40:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from ob3-5.mailhostbox.com (ob3-5.mailhostbox.com [162.222.225.27])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 766EF112
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Aug 2016 10:39:58 +0000 (UTC)
Received: from [0.0.0.0] (unknown [91.233.106.121])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id 91DFE360551
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Aug 2016 10:39:55 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
s=20110108; t=1470479997;
bh=6LXFHJYdIah4N3eK2TuMAeVqJl3HVYnL5DQIReC52+U=;
h=Reply-To:Subject:References:To:From:Date:In-Reply-To;
b=Q0hClUw5K1N2xiuEtDl8AuBfRNgkzdsjViBEFygm945OXJ1r0plG0Fnpkw9F5X1SR
gIpO4R9ZX/Qh3tLL+speMT4D3hu/99ewXxH1JC1PeKn2xXnf6XWPTm4FKtv/2DZs07
bsN11mwNJ7bRLxQM+wHG2uzJOGNgciGgrm/h4d5M=
Reply-To: s7r@sky-ip.org
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
From: s7r <s7r@sky-ip.org>
Message-ID: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
Date: Sat, 6 Aug 2016 13:39:33 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="HaHtESRvE7FuXewj4dW8rJknM0XobgfvN"
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=CPOKJUfD c=1 sm=1 tr=0
a=pwDiKkRGbLWOb7Uqv8I+GA==:117 a=pwDiKkRGbLWOb7Uqv8I+GA==:17
a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10
a=13zjGPudsaEWiJwPRgMA:9 a=WbPmnYzAfxEA:10 a=PWoRtCwmAbJYflIwRYwA:9
a=r6i-VSsdHQ2bv6Tw:21 a=Dnar4EMMAh8SdSVE:21 a=pILNOxqGKmIA:10
a=kPwr094j9fgA:10 a=SyZ90x-_52qMzEx18tUA:9
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,URIBL_BLACK autolearn=no
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP clearing house addresses
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: Sat, 06 Aug 2016 10:40:06 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HaHtESRvE7FuXewj4dW8rJknM0XobgfvN
Content-Type: multipart/mixed; boundary="4VSsdi0qeQng7PS7oo5l9tcQwFbtEEcsF"
From: s7r <s7r@sky-ip.org>
Reply-To: s7r@sky-ip.org
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
Subject: Re: [bitcoin-dev] BIP clearing house addresses
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
--4VSsdi0qeQng7PS7oo5l9tcQwFbtEEcsF
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi,
I can clearly see some advantages for such a feature, but it's kind of
in conflict with Bitcoin's fundamental design. This design might be
problematic when it comes to hacks/thefts, but it's what gives Bitcoin
strength and make it differentiate from other currencies:
* reversal of transactions is impossible
* keep private keys private and safe. Lose them, it's like losing cash,
you can just forget about it.
* while we try hard to make 0-conf as safe as possible (if there's no
RBF flag on the transaction), we make it almost impossible or very very
expensive to reverse a confirmed transaction.
Also, we don't have a clear way to properly decide a good settlement
period length. It doesn't fix the problem any more than nLockTime fixes
it -- you can't know ahead of time when a withdraw needs to be made.
Fair enough, but even if the withdraw is made with a settlement layer,
will the user be able to spend it further immediately? Who will accept
such an input and treat it as a payment if it can be reversed during the
settlement layer? So, if you can't know ahead of time when a withdraw
needs to be made (nLockTime) how can you know ahead of time+settlement
period when a transaction needs to be declared irrevocable?
The linked page describes that merchants will never accept payments from
'vaults', and it will take 24 hours for coins to be irreversible moved
outside the 'vault'. This covers the part "is the user able to spend a
transaction with settlement layer" but it has security properties equal
to nLockTime =3D 24 hours - you can't benefit and use the coins
immediately and in 24 hours price might go up or down in an undesirable
way for a certain user. It however raises a lot of other questions: what
if the attacker manages to steal both the private key and vault key (we
have strong reasons to assume this can happen: if you can't keep a
private key safe, why would you be able to keep the vault key any
safer?) and starts a race with the actual user to unlock and lock back
the vault?
I think this is a wrong approach. hacks and big losses are sad, but all
the time users / exchanges are to blame for wrong implementations or
terrible security practices.
Thanks!
On 8/3/2016 9:16 PM, Matthew Roberts via bitcoin-dev wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement laye=
r
> that can be used to revoke transactions?
>=20
> You could specify so that transactions "sent" from these addresses must=
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a
> transaction's progress was publicly visible so transparent fraud
> prevention and auditing would become possible by anyone.
>=20
> The reason why I bring this up is existing OP codes and TX types don't
> seem suitable for a secure clearing mechanism; Nlocktimed TXs won't wor=
k
> for this since you can't know ahead of time when and where a withdrawal=
> needs to be made, plus there's still the potential for key
> mismanagement; Similar problems with OP_CHECKLOCKTIMEVERIFY apply too =96=
> unless you keep a private key around on the server which would defeat
> the purpose. The main use case here, would be specifically to improve
> centralized exchange security by making it impossible for a hot wallet
> to be raided all at once.
>=20
> Thoughts?
>=20
> Some existing background:
>=20
> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-=
been-avoided/
> -- Proposed the basic idea for a time-based clearing house but using
> blockchains directly, this is a much better idea than my own.
>=20
> roberts.pm/timechain <http://roberts.pm/timechain> -- My original paper=
> written in 2015 which proposed a similar idea for secure wallet design
> but implemented using time-locked ECDSA keys. Obviously a blockchain
> would work better for this.
>=20
> Other -- if the idea has already been brought up by other people, I
> apologize.
>=20
--4VSsdi0qeQng7PS7oo5l9tcQwFbtEEcsF--
--HaHtESRvE7FuXewj4dW8rJknM0XobgfvN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJXpb50AAoJEIN/pSyBJlsRNDIIAK+2e8DgfjxNnMKVrsC+k77O
bzUmwRDGk6y+bqG76sUqZySSVB7OaqjhuB8CeIBmSBInZ3cRfH2u/MVKyxT2SUju
bNlyTN3gXcPnFaAZ5IPTIM5ibjTNtjM0IR0QD/v63iCOD6z504uAflAfvmGjd7le
g3lL/1iw86LnXNw2lzR+uYO6ZqIOD9LX9LIh8oXSaU4Oi/A/unVpDv0LQ+2eIOMg
Sa5K2HEWus5NLDGg5PZju2t4pn1N1JEtQ6BeuBHHFpcti9rd9vVE8qDdsw2bQbTu
jWSVXYfWXWTr/zacFUejtHsm7eMoDy0il2yDHi0CNuJ3a1UKKA9/pbHFO6zBRbU=
=9xIK
-----END PGP SIGNATURE-----
--HaHtESRvE7FuXewj4dW8rJknM0XobgfvN--
|
