summaryrefslogtreecommitdiff
path: root/c4/18d17115a4f72df151870287a390df68741899
blob: 61a8be51836af42fb57b9a143429c563539731ba (plain)
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
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 <melvincarvalho@gmail.com>) id 1Ukia0-0008TF-Gc
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Jun 2013 22:22:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.176 as permitted sender)
	client-ip=209.85.217.176; envelope-from=melvincarvalho@gmail.com;
	helo=mail-lb0-f176.google.com; 
Received: from mail-lb0-f176.google.com ([209.85.217.176])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UkiZz-0002nV-0P
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Jun 2013 22:22:48 +0000
Received: by mail-lb0-f176.google.com with SMTP id z5so3586024lbh.21
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 06 Jun 2013 15:22:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.137.73 with SMTP id qg9mr818994lbb.87.1370557360179;
	Thu, 06 Jun 2013 15:22:40 -0700 (PDT)
Received: by 10.112.2.8 with HTTP; Thu, 6 Jun 2013 15:22:40 -0700 (PDT)
In-Reply-To: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
References: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
Date: Fri, 7 Jun 2013 00:22:40 +0200
Message-ID: <CAKaEYhKiRutKYeQjLocJJ0L2Yra790WnUiF5Px64Kxv7Q-0z8w@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Peter Vessenes <peter@coinlab.com>
Content-Type: multipart/alternative; boundary=089e01177551990fc304de83c064
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
	(melvincarvalho[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: 1UkiZz-0002nV-0P
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 22:22:48 -0000

--089e01177551990fc304de83c064
Content-Type: text/plain; charset=ISO-8859-1

On 6 June 2013 02:19, Peter Vessenes <peter@coinlab.com> 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.
>

Also see satoshi's comments on this, though it may be restating what others
have said:

https://bitcointalk.org/index.php?topic=750.0

"Here's an outline of the kind of escrow transaction that's possible in
software.  This is not implemented and I probably won't have time to
implement it soon, but just to let you know what's possible.

The basic escrow: The buyer commits a payment to escrow. The seller
receives a transaction with the money in escrow, but he can't spend it
until the buyer unlocks it. The buyer can release the payment at any time
after that, which could be never. This does not allow the buyer to take the
money back, but it does give him the option to burn the money out of spite
by never releasing it. The seller has the option to release the money back
to the buyer.

While this system does not guarantee the parties against loss, it takes the
profit out of cheating.

If the seller doesn't send the goods, he doesn't get paid. The buyer would
still be out the money, but at least the seller has no monetary motivation
to stiff him.

The buyer can't benefit by failing to pay. He can't get the escrow money
back. He can't fail to pay due to lack of funds. The seller can see that
the funds are committed to his key and can't be sent to anyone else.

Now, an economist would say that a fraudulent seller could start
negotiating, such as "release the money and I'll give you half of it back",
but at that point, there would be so little trust and so much spite that
negotiation is unlikely. Why on earth would the fraudster keep his word and
send you half if he's already breaking his word to steal it? I think for
modest amounts, almost everyone would refuse on principle alone."


>
> Peter
>
> --
>
> ------------------------------
>
> [image: CoinLab Logo]PETER VESSENES
> CEO
>
> *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
>
>

--089e01177551990fc304de83c064
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 6 June 2013 02:19, Peter Vessenes <span dir=3D"ltr">&lt;<a href=
=3D"mailto:peter@coinlab.com" target=3D"_blank">peter@coinlab.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">So, this=
 <a href=3D"http://www.americanbanker.com/bankthink/the-last-straw-for-bitc=
oin-1059608-1.html?pg=3D1" target=3D"_blank">http://www.americanbanker.com/=
bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=3D1</a> =A0article g=
ot posted today, noting that FinCEN thinks irrevocable payments are money l=
aundering tools.=A0<div>


<br></div><div>I will hold my thoughts about the net social good of rent-se=
eking large corporations taking money from consumers over fraudulent revers=
als. Actually, I won&#39;t, I just said it.<br><div><br></div><div>At any r=
ate, it got me thinking, can we layer on revocability somehow without any p=
rotocol change, as an opt-in?</div>


<div><br></div><div>My initial scheme is a trusted (hah) escrow service tha=
t issues time promises for signing. If it doesn&#39;t receive a cancel mess=
age, it will sign at the end of the time.=A0</div><div><br></div><div>The a=
ddresses 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 trans=
action go out.</div>


<div><br></div><div>This seems sort of poor to me, it imagines that mythica=
l thing, a trusted escrow service, and is vulnerable to griefing, but I tho=
ught I&#39;d see if some of the brighter minds than me can come up with a l=
ayer-on approach here.</div>


<div><br></div><div>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 ha=
ve warning if someone wanted to try and spend them, and could do something =
about it. I&#39;m not sure if it gets me anything over a standard escrow ar=
rangement, though.</div>
</div></div></blockquote><div><br></div><div>Also see satoshi&#39;s comment=
s on this, though it may be restating what others have said:<br><br><a href=
=3D"https://bitcointalk.org/index.php?topic=3D750.0">https://bitcointalk.or=
g/index.php?topic=3D750.0</a><br>
<br>&quot;Here&#39;s an outline of the kind of escrow transaction that&#39;=
s possible in software.=A0 This is not implemented and I probably won&#39;t=
 have time to implement it soon, but just to let you know what&#39;s possib=
le.<br>
<br>The basic escrow: The buyer commits a payment to escrow. The seller rec=
eives a transaction with the money in escrow, but he can&#39;t spend it unt=
il the buyer unlocks it. The buyer can release the payment at any time afte=
r that, which could be never. This does not allow the buyer to take the mon=
ey back, but it does give him the option to burn the money out of spite by =
never releasing it. The seller has the option to release the money back to =
the buyer.<br>
<br>While this system does not guarantee the parties against loss, it takes=
 the profit out of cheating.<br><br>If the seller doesn&#39;t send the good=
s, he doesn&#39;t get paid. The buyer would still be out the money, but at =
least the seller has no monetary motivation to stiff him.<br>
<br>The buyer can&#39;t benefit by failing to pay. He can&#39;t get the esc=
row money back. He can&#39;t fail to pay due to lack of funds. The seller c=
an see that the funds are committed to his key and can&#39;t be sent to any=
one else.<br>
<br>Now, an economist would say that a fraudulent seller could start negoti=
ating, such as &quot;release the money and I&#39;ll give you half of it bac=
k&quot;, but at that point, there would be so little trust and so much spit=
e that negotiation is unlikely. Why on earth would the fraudster keep his w=
ord and send you half if he&#39;s already breaking his word to steal it? I =
think for modest amounts, almost everyone would refuse on principle alone.&=
quot;<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div><span class=3D""><font color=3D"#888888">

<div><br></div><div>Peter<br clear=3D"all"><div><br></div>-- <br><div dir=
=3D"ltr"><br><hr style=3D"font-family:Times;font-size:medium;border-right-w=
idth:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:sol=
id;border-top-color:rgb(204,204,204);margin:10px 0px">


<p style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1=
em"><span style=3D"color:rgb(50,90,135);text-transform:uppercase"><img alt=
=3D"CoinLab Logo" width=3D"130" align=3D"right">PETER=A0<span style=3D"font=
-weight:bold">VESSENES=A0</span><br>


<span style=3D"color:rgb(96,58,23);font-size:0.8em">CEO</span></span></p><p=
 style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1em=
"><span style=3D"color:rgb(96,58,23);font-size:0.9em"><b><a href=3D"mailto:=
peter@coinlab.com" style=3D"text-decoration:none;color:rgb(96,58,23)" targe=
t=3D"_blank">peter@coinlab.com</a>=A0</b>=A0/=A0=A0<a href=3D"tel:206.486.6=
856" value=3D"+12064866856" target=3D"_blank">206.486.6856</a> =A0/=A0<span=
 style=3D"font-size:0.7em;text-transform:uppercase">SKYPE:</span>=A0vessene=
s=A0</span><br>


<span style=3D"color:rgb(96,58,23);font-size:0.7em;text-transform:uppercase=
">71 COLUMBIA ST / SUITE 300 =A0/=A0 SEATTLE, WA 98104</span></p></div>
</div></font></span></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
How ServiceNow helps IT people transform IT departments:<br>
1. A cloud service to automate IT design, transition and operations<br>
2. Dashboards that offer high-level views of enterprise services<br>
3. A single system of record for all IT processes<br>
<a href=3D"http://p.sf.net/sfu/servicenow-d2d-j" target=3D"_blank">http://p=
.sf.net/sfu/servicenow-d2d-j</a><br>_______________________________________=
________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>

--089e01177551990fc304de83c064--