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
|
Return-Path: <matthew@roberts.pm>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1016178D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2016 18:16:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f48.google.com (mail-it0-f48.google.com
[209.85.214.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53E931BC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2016 18:16:21 +0000 (UTC)
Received: by mail-it0-f48.google.com with SMTP id j124so242082672ith.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 03 Aug 2016 11:16:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=roberts-pm.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=+WXZ6E90Jw8OpxRzqB7D9uuR7TFqbhULJJt60RWW6hQ=;
b=EhrdBcbX4hftmA7ituY5z76R9vR5BRv1m0np6RmBkUre6s5ycn4sddOv3zMhwJaqjG
YyWAOkHRJPGzCZwj/YF39SToKDNZnSsDE2dGskQpdl2JVaFnyva0Y897Wdcll443WQL/
Mkiyp9uyXUC5ic3xpENQ9F77ycvs5zQdUaTrFZ5z3x7f/kiAeljCVlH3ssZM51YLQ01g
D8T7aiiznEiSyAmDh2mukQF7LwKrz7RXv55SRBJmU74RG9TIMQevNMNeT0GbxUfBp0mB
u/zyyv3cVZGK4f0aYEovnIuqLYyXty4FThmqKJieDMAUvSWNlRmjpJpK+tqW7kdWqIto
EiFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=+WXZ6E90Jw8OpxRzqB7D9uuR7TFqbhULJJt60RWW6hQ=;
b=lDIqvFFuRNcP/H8V6dEZQ/Nmn1FiKmr7QGnA8IoY7quAsLnAgxofkGt3waPEugsTUM
/8/vOQG6Jg5Yg8JgPRv5cPCzkVNhaZtZ6RBLZcOgSmpBXT4LaN0iduuUJq/oY4kDqXCT
34GefRFYDV6QPWs07N0T/kM5AyCGid0YSZFLV6vau4NtZ5X4xr7kerjHWouU5y9XX1bY
/5/PLuuUMNL62vCw4MWZYrsj4xyYiYLVCnqWCpWXJ0bwQGJOXdG/362V6YXbOur2JiYx
jFufzJHt2Wz6srsZlZKY92Nkq9bTTmxdW9MAhpmHgPp28L/noTo+xRg3kDHvjcCwnfv+
R59Q==
X-Gm-Message-State: AEkoout7O/X+Vm+AlMiioLiQC3V9M0Y61+lhyWZcYdxvV8Cc9aJU3voZ4f9nmq6Y4zGBZQ7FDYSHUPv466725w==
X-Received: by 10.36.239.197 with SMTP id i188mr24977748ith.71.1470248180423;
Wed, 03 Aug 2016 11:16:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.57.69 with HTTP; Wed, 3 Aug 2016 11:16:20 -0700 (PDT)
X-Originating-IP: [115.70.56.56]
From: Matthew Roberts <matthew@roberts.pm>
Date: Thu, 4 Aug 2016 04:16:20 +1000
Message-ID: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c11645686cf1605392ed42d
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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, 03 Aug 2016 18:26:06 +0000
Subject: [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: Wed, 03 Aug 2016 18:16:23 -0000
--94eb2c11645686cf1605392ed42d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 layer
that can be used to revoke transactions?
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.
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 work 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 =E2=80=93 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.
Thoughts?
Some existing background:
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.
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.
Other -- if the idea has already been brought up by other people, I
apologize.
--94eb2c11645686cf1605392ed42d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">
<p style=3D"margin-bottom:0in">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 layer that can be used to revoke
transactions?</p>
<p style=3D"margin-bottom:0in">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 the=
ir 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.<br></p>
<p style=3D"margin-bottom:0in">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 work 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 =E2=80=93 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 centraliz=
ed exchange security by making it impossible for a hot wallet to be raided =
all at once.
</p><p style=3D"margin-bottom:0in">Thoughts?</p><p style=3D"margin-bottom:0=
in">Some existing background:</p><p style=3D"margin-bottom:0in"><a href=3D"=
http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been=
-avoided/">http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-coul=
d-have-been-avoided/</a> -- Proposed the basic idea for a time-based cleari=
ng house but using blockchains directly, this is a much better idea than my=
own.</p><p style=3D"margin-bottom:0in"><a href=3D"http://roberts.pm/timech=
ain">roberts.pm/timechain</a> -- My original paper written in 2015 which pr=
oposed a similar idea for secure wallet design but implemented using time-l=
ocked ECDSA keys. Obviously a blockchain would work better for this.<br></p=
><p style=3D"margin-bottom:0in">Other -- if the idea has already been broug=
ht up by other people, I apologize. <br></p><p style=3D"margin-bottom:0in">=
<br>
</p>
<p style=3D"margin-bottom:0in"><br>
</p>
</div>
--94eb2c11645686cf1605392ed42d--
|
