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
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5632E724
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2016 03:49:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 57DCD121
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2016 03:49:28 +0000 (UTC)
Received: by mail-ua0-f175.google.com with SMTP id j59so166538936uaj.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 03 Aug 2016 20:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=I+C6494tFIXk2ztvOSP+JOwTM/ejYNz0FO5E7GxfoQE=;
b=oJQnZ/x+D2AJznaeK8eVN7F6UnqAHFMZgq1UqRtbw1+h8rLh+6J549Ks/X5h+4rlzs
AfCzTbkwRRRBavPPXjyWgvHLJMJqZMb7spx/9mm57k0zwpVoM0N357F9Fu32sWIlI9gp
BdDpQV78vEM6QjhzfD5tmEH9zXuO4cNJwinYBn9CyVxs2TQ8WdagOgrBIF4wkb21vbYj
oWHu4VJyxqmO21hHJy0FR+A2/vp/goQyL5IWN94eQ5pSQ7UgFE3INGCv6s1yEwh2uYFu
cMtvWBSc5Eo9gQDwcGW0FTf0gOCBbg5jAxXoqDHZPKylOS62qNC5TiWaPQwjlp7K506O
Ntdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=I+C6494tFIXk2ztvOSP+JOwTM/ejYNz0FO5E7GxfoQE=;
b=jAYRQ3nqGG8a1alZ3ZgfqCcYRned5kcLbYpsppsFs7IkPxHlxzdcCXfJWqSurnSSVq
rUQtt5xbmY0eIRLTjQzNmla+bvnpMjva1kzwLXEUQwX8sq2QiSWDWjenct9Bor5X3q/7
Pn2hxGqPBhkI+ype2QMC8jKZtAUFnu/ck/5GYvQwDY8WQN7wFSJFUmQJqggTvsym9mZx
rstozdhDE2raSDysjOPpMrb99oP7r5+YXuM+5PZmwUbDCSPXf1HNfgcr4bG0w/Oew3zr
eTmfA+RlcxplCAB/yxYE9lZ4iSO5j2B7c+TXzo/kbUXpJStR4XoXcEa2mxphd2CPNjHP
7RIw==
X-Gm-Message-State: AEkooutTQNem8hvaT/pd9axPiZf6pSkcbfKZWAGOF+qDExnciPW7R8vaADPORIyJok9Vjzl2x5Aje1um1wyyFw==
X-Received: by 10.159.40.167 with SMTP id d36mr32130004uad.60.1470282567468;
Wed, 03 Aug 2016 20:49:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.64.150 with HTTP; Wed, 3 Aug 2016 20:49:26 -0700 (PDT)
Received: by 10.103.64.150 with HTTP; Wed, 3 Aug 2016 20:49:26 -0700 (PDT)
In-Reply-To: <201608040327.36571.luke@dashjr.org>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
<201608040327.36571.luke@dashjr.org>
From: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Wed, 3 Aug 2016 23:49:26 -0400
Message-ID: <CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c123794274f7a053936d6f9
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
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: Thu, 04 Aug 2016 09:07:44 +0000
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: Thu, 04 Aug 2016 03:49:29 -0000
--94eb2c123794274f7a053936d6f9
Content-Type: text/plain; charset=UTF-8
"This is already possible. Just nLockTime your withdrawls for some future
block. Don't sign any transaction that isn't nLockTime'd at least N blocks
beyond the present tip."
This would have prevented the Bitfinex hack if BitGo did this, but it
wouldn't have helped if the Bitfinex offline key had been compromised
instead of BitGo doing the 2nd sig. In the BFX hack the TXNs were signed
by Bitfinex's hot key and BitGo's key, they required 2 of 2.
If I'm understanding correctly, what Matthew is proposing is a new type of
UTXO that is only valid to be spent as an nLockTime transaction and can be
reversed by some sort of RBF-type transaction within that time period, I
believe.
But I don't think this will work. What do you do if the keys are
compromised? What's to stop the attacker from locking the coins up
indefinitely by repeatedly broadcasting a refund transaction each time you
try to spend to an uncompromised address?
You'd need a third distinct key required for the refund TXN that's separate
from the keys used to sign the initial nLockTime TXN. And the refund TXN
would need to be able to go to a new address entirely.
On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wednesday, August 03, 2016 6:16:20 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 layer
> > that can be used to revoke transactions?
>
> This isn't something that makes sense at the address, since it represents
> the
> recipient and not the sender. Transactions are not sent from addresses
> ever.
>
> > 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.
>
> This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--94eb2c123794274f7a053936d6f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">"This is already possible. Just nLockTime your withdraw=
ls for some future<br>
block. Don't sign any transaction that isn't nLockTime'd at lea=
st N blocks<br>
beyond the present tip."</p>
<p dir=3D"ltr">This would have prevented the Bitfinex hack if BitGo did thi=
s, but it wouldn't have helped if the Bitfinex offline key had been com=
promised instead of BitGo doing the 2nd sig.=C2=A0 In the BFX hack the TXNs=
were signed by Bitfinex's hot key and BitGo's key, they required 2=
of 2.</p>
<p dir=3D"ltr">If I'm understanding correctly, what Matthew is proposin=
g is a new type of UTXO that is only valid to be spent as an nLockTime tran=
saction and can be reversed by some sort of RBF-type transaction within tha=
t time period, I believe.</p>
<p dir=3D"ltr">But I don't think this will work. What do you do if the =
keys are compromised?=C2=A0 What's to stop the attacker from locking th=
e coins up indefinitely by repeatedly broadcasting a refund transaction eac=
h time you try to spend to an uncompromised address?</p>
<p dir=3D"ltr">You'd need a third distinct key required for the refund =
TXN that's separate from the keys used to sign the initial nLockTime TX=
N.=C2=A0 And the refund TXN would need to be able to go to a new address en=
tirely.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Aug 3, 2016 11=
:28 PM, "Luke Dashjr via bitcoin-dev" <<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wedne=
sday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev<br>
wrote:<br>
> In light of the recent hack: what does everyone think of the idea of<b=
r>
> creating a new address type that has a reversal key and settlement lay=
er<br>
> that can be used to revoke transactions?<br>
<br>
This isn't something that makes sense at the address, since it represen=
ts the<br>
recipient and not the sender. Transactions are not sent from addresses ever=
.<br>
<br>
> You could specify so that transactions "sent" from these add=
resses must<br>
> receive N confirmations before they can't be revoked, after which =
the<br>
> transaction is "settled" and the coins become redeemable fro=
m their<br>
> destination output. A settlement phase would also mean that a transact=
ion's<br>
> progress was publicly visible so transparent fraud prevention and audi=
ting<br>
> would become possible by anyone.<br>
<br>
This is already possible. Just nLockTime your withdrawls for some future<br=
>
block. Don't sign any transaction that isn't nLockTime'd at lea=
st N blocks<br>
beyond the present tip.<br>
<br>
Luke<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
--94eb2c123794274f7a053936d6f9--
|
