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
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1UkOBB-000850-1j
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Jun 2013 00:35:49 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.172 as permitted sender)
client-ip=209.85.223.172; envelope-from=etotheipi@gmail.com;
helo=mail-ie0-f172.google.com;
Received: from mail-ie0-f172.google.com ([209.85.223.172])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UkOB8-0004QY-Rw
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Jun 2013 00:35:49 +0000
Received: by mail-ie0-f172.google.com with SMTP id 17so5457916iea.17
for <bitcoin-development@lists.sourceforge.net>;
Wed, 05 Jun 2013 17:35:41 -0700 (PDT)
X-Received: by 10.42.102.211 with SMTP id j19mr16092647ico.0.1370478941512;
Wed, 05 Jun 2013 17:35:41 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id r20sm8673047ign.8.2013.06.05.17.35.40
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 05 Jun 2013 17:35:40 -0700 (PDT)
Message-ID: <51AFD92F.1020206@gmail.com>
Date: Wed, 05 Jun 2013 20:34:55 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
In-Reply-To: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
boundary="------------070809070101090002050907"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UkOB8-0004QY-Rw
Subject: Re: [Bitcoin-development] Revocability with known trusted escrow
services?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 00:35:49 -0000
This is a multi-part message in MIME format.
--------------070809070101090002050907
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
The two most basic ways would be simply:
(1) You create your transactions having a locktime of X days and has
sequence numbers such that it can be replaced exactly once. The
replacement, can be executed within 30 days.
(2) You simply send money to 1-of-2 transactions: me-or-you. If the
person who is receiving it wants it, they have to sign for it by sending
it to one of their own single-sig addresses. Otherwise, you can return
it to yourself at some point in the future.
I don't totally understand the goal, and how/if these solutions actually
achieve such goal. But it does add a way for transactions to exist a
non-final state for some amount of time. But in both cases,
accessibility is still binary: you have complete access to it, until
you don't. Which might be seen as the point of irrevocable transfer.
-Alan
On 06/05/2013 08:19 PM, Peter Vessenes wrote:
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
> article got posted today, noting that FinCEN thinks irrevocable
> payments are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking
> large corporations taking money from consumers over fraudulent
> reversals. Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will
> sign at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period
> when you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a
> trusted escrow service, and is vulnerable to griefing, but I thought
> I'd see if some of the brighter minds than me can come up with a
> layer-on approach here.
>
> When I think about it, I can imagine that I would put a good number of
> my coins in a one day reversible system, because I would have warning
> if someone wanted to try and spend them, and could do something about
> it. I'm not sure if it gets me anything over a standard escrow
> arrangement, though.
>
> Peter
>
> --
>
> ------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter@coinlab.com <mailto:peter@coinlab.com> * / 206.486.6856
> / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------070809070101090002050907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
The two most basic ways would be simply:<br>
<br>
(1) You create your transactions having a locktime of X days and has
sequence numbers such that it can be replaced exactly once. The
replacement, can be executed within 30 days.<br>
<br>
(2) You simply send money to 1-of-2 transactions: me-or-you. If
the person who is receiving it wants it, they have to sign for it by
sending it to one of their own single-sig addresses. Otherwise, you
can return it to yourself at some point in the future.<br>
<br>
I don't totally understand the goal, and how/if these solutions
actually achieve such goal. But it does add a way for transactions
to exist a non-final state for some amount of time. But in both
cases, accessibility is still binary: you have complete access to
it, until you don't. Which might be seen as the point of
irrevocable transfer.<br>
<br>
-Alan<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 06/05/2013 08:19 PM, Peter Vessenes
wrote:<br>
</div>
<blockquote
cite="mid:CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com"
type="cite">
<div dir="ltr">So, this <a moz-do-not-send="true"
href="http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1">http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1</a>
article got posted today, noting that FinCEN thinks irrevocable
payments are money laundering tools.
<div>
<br>
</div>
<div>I will hold my thoughts about the net social good of
rent-seeking large corporations taking money from consumers
over fraudulent reversals. Actually, I won't, I just said it.<br>
<div><br>
</div>
<div>At any rate, it got me thinking, can we layer on
revocability somehow without any protocol change, as an
opt-in?</div>
<div><br>
</div>
<div>My initial scheme is a trusted (hah) escrow service that
issues time promises for signing. If it doesn't receive a
cancel message, it will sign at the end of the time. </div>
<div><br>
</div>
<div>The addresses would be listed by the escrow service, or
in an open registry, so you could see if you were going to
have a delay period when you saw a transaction go out.</div>
<div><br>
</div>
<div>This seems sort of poor to me, it imagines that mythical
thing, a trusted escrow service, and is vulnerable to
griefing, but I thought I'd see if some of the brighter
minds than me can come up with a layer-on approach here.</div>
<div><br>
</div>
<div style="">When I think about it, I can imagine that I
would put a good number of my coins in a one day reversible
system, because I would have warning if someone wanted to
try and spend them, and could do something about it. I'm not
sure if it gets me anything over a standard escrow
arrangement, though.</div>
<div style=""><br>
</div>
<div>Peter<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"><br>
<hr
style="font-family:Times;font-size:medium;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-top-color:rgb(204,204,204);margin:10px
0px">
<p
style="font-size:medium;font-family:Helvetica,sans-serif;line-height:1em"><span
style="color:rgb(50,90,135);text-transform:uppercase"><img
moz-do-not-send="true"
src="http://coinlab.com/static/images/email_logo.jpg"
alt="CoinLab Logo" width="130" align="right">PETER <span
style="font-weight:bold">VESSENES </span><br>
<span style="color:rgb(96,58,23);font-size:0.8em">CEO</span></span></p>
<p
style="font-size:medium;font-family:Helvetica,sans-serif;line-height:1em"><span
style="color:rgb(96,58,23);font-size:0.9em"><strong><a
moz-do-not-send="true"
href="mailto:peter@coinlab.com"
style="text-decoration:none;color:rgb(96,58,23)"
target="_blank">peter@coinlab.com</a> </strong> / 206.486.6856
/ <span
style="font-size:0.7em;text-transform:uppercase">SKYPE:</span> vessenes </span><br>
<span
style="color:rgb(96,58,23);font-size:0.7em;text-transform:uppercase">71
COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104</span></p>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/servicenow-d2d-j">http://p.sf.net/sfu/servicenow-d2d-j</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------070809070101090002050907--
|
