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
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
|
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 1A99B413
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2016 04:53:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
[209.85.223.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 703CC13B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2016 04:53:19 +0000 (UTC)
Received: by mail-io0-f172.google.com with SMTP id m101so262091210ioi.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 03 Aug 2016 21:53:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=roberts-pm.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=gnVVYEMZus8XjtHQioEeTGSMEcw7Jn8hiI0e6WsF4Y0=;
b=x5jT3Bbc67xB+qN+r60g9of0aS7I9rV4B2dOdwC2iuXHynm6uVzV+i0Nba3jEgJ/pX
AG++YmDhimyByK5sXl6zDkhLhqJfGgHqVlrfVfHrClRneaFNJSD7ZYuvWdXjCQU7NlJ5
5HxEr7V1fHPVVqPdamLQyQbBBSiorCf5gQJLpchZvOdMbdDv/xMKaRILtJL9wELep1JS
xDJ4MxtOV0O8WpFARucBfrocCUopsjipiWAwuJ9UPizORTPyxsHSkuFSne4SxcAgBS31
RSkDNkoKBF3k0X1WpikhRtCkp83O4l6FDaem2ohpw5vqf4Epi6xUyLep0VhwR06l0K36
qzow==
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=gnVVYEMZus8XjtHQioEeTGSMEcw7Jn8hiI0e6WsF4Y0=;
b=j8FdUvaMUG0aSy0zAGePhI+BsZA7KH0NTsAgh5f61SB7jPyitn0UnJ5j0bQYuUijs0
DXWT+/lT841d/732YmHLmuXCqZ7TaTFiLsdZVcchFDorHMAzZ3rFoieZDDFUEiDTfsus
efv0bhJCiGTzRVHZSE6XLunMeE9lebXwu4bGyIwzU7syfpkpYVAFNuTpOTiyMETiSN1X
r+H1o3Pkc3w1RBs15iMiPkV3lwqYzTvm7rjIlbYmeAg7lqM0qjHC1rv5NdxU09/3udV+
FQAT40h3HqdB522UAbq5ZaDHAsc9KHfACnD/wQiBM5r6IwxxPpijBDtAh9TLPoLzfTUj
LZZA==
X-Gm-Message-State: AEkoouuywgXGTFZZ3pFQW6oJChsgFXfAKSjfNHVBMZlKPB9SDPrv3pfRAmq2ukd3eVpN/qsIwE/W03Yx60FtaA==
X-Received: by 10.107.23.66 with SMTP id 63mr80329600iox.169.1470286398714;
Wed, 03 Aug 2016 21:53:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.57.69 with HTTP; Wed, 3 Aug 2016 21:53:18 -0700 (PDT)
X-Originating-IP: [115.70.56.56]
In-Reply-To: <CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
<201608040327.36571.luke@dashjr.org>
<CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>
From: Matthew Roberts <matthew@roberts.pm>
Date: Thu, 4 Aug 2016 14:53:18 +1000
Message-ID: <CAAEDBiGYz+q=1iTEQjQu2ewDw7QRS+EZQOrq6v4y6Z9RT+e-aQ@mail.gmail.com>
To: Andrew Johnson <andrew.johnson83@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c05c23e83b14a053937ba38
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: Thu, 04 Aug 2016 09:05:55 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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: Thu, 04 Aug 2016 04:53:21 -0000
--94eb2c05c23e83b14a053937ba38
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.
The problem with nLockTimed transactions is a centralized exchange isn't
going to know ahead of time where those locked transactions need to go or
the amount that needs to be signed so you will end up having to keep the
private key around. If there was a way to create these transactions offline
with special SIG_HASH flags (and I don't think there is) there's nothing
about nLockTime that forces that the transactions be broadcast straight
away and plus: since the TXs aren't confirmed until the lock-time expires
they can be overwritten anyway.
I think given the requirements that a centralized exchange has: TierNolan's
idea is the best so far. Essentially, you have a new type of output script
that forces the redeemer to use a designated output script template in the
redeeming transaction, meaning that you can actually force people to send
coins into another transaction with "relative lock-timed" outputs. The new
transaction can then only be redeemed at the destination after the relative
lock-time expires OR it can be moved before-hand to a designated off-line
recovery address. This is much better than creating a new transaction
system, IMO.
>And the refund TXN would need to be able to go to a new address entirely.
Agreed.
On Thu, Aug 4, 2016 at 1:49 PM, Andrew Johnson <andrew.johnson83@gmail.com>
wrote:
> "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
>>
>
--94eb2c05c23e83b14a053937ba38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>>This is already possible. Just nLockTime you=
r 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>The problem with nLockTimed transactions is =
a centralized exchange isn't going to know ahead of time where those lo=
cked transactions need to go or the amount that needs to be signed so you w=
ill end up having to keep the private key around. If there was a way to cre=
ate these transactions offline with special SIG_HASH flags (and I don't=
think there is) there's nothing about nLockTime that forces that the t=
ransactions be broadcast straight away and plus: since the TXs aren't c=
onfirmed until the lock-time expires they can be overwritten anyway.<br><br=
></div>I think given the requirements that a centralized exchange has: Tier=
Nolan's idea is the best so far. Essentially, you have a new type of ou=
tput script that forces the redeemer to use a designated output script temp=
late in the redeeming transaction, meaning that you can actually force peop=
le to send coins into another transaction with "relative lock-timed&qu=
ot; outputs. The new transaction can then only be redeemed at the destinati=
on after the relative lock-time expires OR it can be moved before-hand to a=
designated off-line recovery address. This is much better than creating a =
new transaction system, IMO.<br><br>>And the refund TXN would need to be=
able to go to a new address entirely.<br><br></div>Agreed.<br></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Aug 4, 2016 at =
1:49 PM, Andrew Johnson <span dir=3D"ltr"><<a href=3D"mailto:andrew.john=
son83@gmail.com" target=3D"_blank">andrew.johnson83@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr">=
"This is already possible. Just nLockTime your withdrawls for some fut=
ure<br>
block. Don't sign any transaction that isn't nLockTime'd at lea=
st N blocks<br>
beyond the present tip."</p>
</span><p dir=3D"ltr">This would have prevented the Bitfinex hack if BitGo =
did this, but it wouldn't have helped if the Bitfinex offline key had b=
een compromised instead of BitGo doing the 2nd sig.=C2=A0 In the BFX hack t=
he TXNs were signed by Bitfinex's hot key and BitGo's key, they req=
uired 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"><div><div class=
=3D"h5">On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attributi=
on"></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">On We=
dnesday, 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></div></div><span class=3D"">
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</span></blockquote></div></div>
</blockquote></div><br></div>
--94eb2c05c23e83b14a053937ba38--
|
